Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.6
Hi, On Fri, Feb 12, 2016 at 08:06:22PM +0100, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC updates for v4.6. > > This pull request is based on "Renesas ARM Based SoC Cleanup for v4.6", > tagged as cleanup-for-v4.6, which you have already pulled. I would like to withdraw this pull request. I noticed that there is an error in the base I chose for the pull request which has resulted in the inclusion of a patch "ARM: shmobile: Consolidate SCU mapping code", which is already present in your tree due to another pull request of mine which you have accepted. I will respin this pull request accordingly. > The following changes since commit e24f317c859f2d904d1eb87cbb503c309e6dead7: > > ARM: shmobile: Typo s/MIPDR/MPIDR/ (2016-02-04 15:09:30 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > tags/renesas-soc-for-v4.6 > > for you to fetch changes up to 9c9c1320111449c770a51488ca74a5902835e227: > > ARM: shmobile: emev2: Move declaration of emev2_smp_ops to emev2.h > (2016-02-09 21:16:16 +0100) > > > Renesas ARM Based SoC Updates for v4.6 > > * Move emev2_smp_ops to emev2 > * Remove legacy map_io callbacks on r8a7740 and emev2 SoCs > * Clean up SCU mapping code > * Migrate to generic l2c OF initialization on r8a7740 > > > Geert Uytterhoeven (8): > ARM: shmobile: r8a7779: Remove remainings of removed SCU boot setup code > ARM: shmobile: r8a7740: Migrate to generic l2c OF initialization > ARM: shmobile: r8a7740: Remove mapping of L2 cache controller registers > ARM: shmobile: Move shmobile_scu_base from .text to .data > ARM: shmobile: Consolidate SCU mapping code > ARM: shmobile: r8a7740: Remove legacy machine_desc.map_io() callback > ARM: shmobile: emev2: Remove legacy machine_desc.map_io() callback > ARM: shmobile: emev2: Move declaration of emev2_smp_ops to emev2.h > > arch/arm/mach-shmobile/common.h| 5 ++--- > arch/arm/mach-shmobile/emev2.h | 6 ++ > arch/arm/mach-shmobile/headsmp-scu.S | 6 -- > arch/arm/mach-shmobile/platsmp-scu.c | 11 -- > arch/arm/mach-shmobile/setup-emev2.c | 22 ++- > arch/arm/mach-shmobile/setup-r8a7740.c | 39 > ++ > arch/arm/mach-shmobile/smp-emev2.c | 5 +++-- > arch/arm/mach-shmobile/smp-r8a7779.c | 5 + > arch/arm/mach-shmobile/smp-sh73a0.c| 3 +-- > 9 files changed, 26 insertions(+), 76 deletions(-) > create mode 100644 arch/arm/mach-shmobile/emev2.h >
Re: [PATCH 00/02] arm64: r8a7795 INTC-EX support using RENESAS_IRQC
Hi Simon, On Wed, Feb 17, 2016 at 2:56 PM, Simon Horman wrote: > On Tue, Feb 16, 2016 at 11:26:35AM +0900, Magnus Damm wrote: >> arm64: r8a7795 INTC-EX support using RENESAS_IRQC >> >> [PATCH 01/02] arm64: dts: r8a7795: Add INTC-EX device node >> [PATCH 02/02] arm64: renesas: Enable RENESAS_IRQC >> >> These two patches add the INTC-EX device node to the r8a7795 DTSI >> file and selects RENESAS_IRQC to enable the irqchip driver. Those >> two together allow r8a7795 based platforms to use external interrupt >> pins IRQ0 -> IRQ5. >> >> The patches in this series can be merged independently in any order, >> but for complete run time support the following two patches are also >> required: >> >> [PATCH] pinctrl: sh-pfc: r8a7795: Add support for INTC-EX IRQ pins >> [PATCH] clk: shmobile: r8a7795: Add INTC-EX clock >> >> The DT compat string "renesas,intc-ex-r8a7795" is already included in >> Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt >> >> Tested on r8a7795 Salvator-X by toggling IRQ2 using an external GPIO >> connected via a loop back adapter on EXIO_D. >> >> Signed-off-by: Magnus Damm > > Thanks, I have queued these up for v4.6. Thanks for your help! / magnus
Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
Hi Simon,
On Wed, Feb 17, 2016 at 3:28 PM, Simon Horman wrote:
> On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote:
>> Hi Geert,
>>
>> On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven
>> wrote:
>> > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm wrote:
>> >> From: Magnus Damm
>> >>
>> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings
>> >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
>> >> features in the driver. The old compat strings will be deprecated in
>> >> the not so distant future.
>> >>
>> >> Signed-off-by: Magnus Damm
>> >> Acked-by: Geert Uytterhoeven
>> >> Acked-by: Laurent Pinchart
>> >> Acked-by: Rob Herring
>> >> ---
>> >>
>> >> Changes since V2:
>> >> - Added Acked-by from Rob
>> >> - Removed Tested-by tag from DT binding patch - duh!
>> >>
>> >> Changes since V1:
>> >> - Added Acked-by and Tested-by from Geert
>> >> - Added Acked-by from Laurent
>> >>
>> >> Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt
>> >> 2015-09-17 17:26:57.440513000 +0900
>> >> @@ -36,6 +36,9 @@ Required Properties:
>> >> (CMT1 on sh73a0 and r8a7740)
>> >> This is a fallback for the above renesas,cmt-48-* entries.
>> >>
>> >> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car
>> >> Gen2.
>> >> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car
>> >> Gen2.
>> >
>> > (advancing a few months always means more comments ;-)
>>
>> Indeed!
>>
>> > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
>>
>> I have no strong feelings one way or the other, but I agree that
>> aiming to make things more consistent must be good.
>
> FWIW, I agree with Geert's suggestion.
> But I also think it is not particularly important.
>
>> Your proposal makes the fallback match with what we do for a bunch
>> other devices on R-Car Gen2 like:
>> "rcar-gen2-cpg-clocks"
>> "rcar-gen2-scif"
>> But we also seem to have:
>> "pci-rcar-gen2"
>
> Bother, it looks like I got pci backwards :(
>
>> On R-Car Gen3 we seem to have the following per-SoC compat strings:
>> "dmac-r8a7795"
>> "etheravb-r8a7795"
>> "gpio-r8a7795"
>> "scif-r8a7795"
>
> I believe the above are to follow the existing pattern for
> per-SoC compat strings in the same driver, which seems sane.
>
>> But we also have:
>> "r8a7795-cpg-mssr"
>>
>> My only feeling is that it looks a tad odd if we follow
>> ",-" for fallback strings but
>> ",-" for the per-soc binding. Why not
>> using the same order? Maybe this is specified in some document
>> somewhere?
>
> I believe that the problem is a historical one. Perhaps when
> we started adding bindings for our hardware there were no clear
> guidelines. But regardless we ended up with a mix as you describe.
Right, that seems to be the way things have happened.
> In the mean time guidelines have emerged and we (or at least I) have
> agreed with the device tree people (probably Rob) to use the
> ,- format for new bindings. My reading is that
> applies even if it results in fallback and non-fallback bindings for the
> same driver have different orders. Some precedence for this can now be found
> in renesas,rcar-dmac.txt.
Some sort of agreed format sounds good.
Your proposal of ,- sounds good to me.
I'm however slightly more confused by seeing that your example
renesas,rcar-dmac.txt included in renesas-drivers-2016-02-16-v4.5-rc4
does not match the proposed format:
$ grep "renesas," Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt
- compatible: "renesas,dmac-", "renesas,rcar-dmac" as fallback.
- "renesas,dmac-r8a7790" (R-Car H2)
- "renesas,dmac-r8a7791" (R-Car M2-W)
- "renesas,dmac-r8a7792" (R-Car V2H)
- "renesas,dmac-r8a7793" (R-Car M2-N)
- "renesas,dmac-r8a7794" (R-Car E2)
- "renesas,dmac-r8a7795" (R-Car H3)
compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
compatible = "renesas,dmac-r8a7790", "renesas,rcar-dmac";
$
> I don't, however, think it applies where we add more soc-specific to a
> driver that already has such bindings. Or new fallback bindings to a driver
> that already has such bindings.
Right, but for rcar-dmac.c there is no matching on per-SoC strings in
the driver so I guess we can pick anything we want?
$ grep "renesas," drivers/dma/sh/rcar-dmac.c
{ .compatible = "renesas,rcar-dmac", },
$
>> I guess your take with "r8a7795-cpg-mssr" above is to follow the same
>> order as for the fallback case? This seems sane to me, and if so then
>> perhaps the per-soc compat strings for the CMT should also be updated?
>> Same for other devices too then, like the recently added
>> "dmac-r8a7795"?
>
> From my point of view it would be nice to clean things up and
> re-
Re: ravb: Possible Regression In "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
On February 16, 2016 3:06:55 AM PST, Sergei Shtylyov
wrote:
>Hello.
>
>On 2/16/2016 10:42 AM, Geert Uytterhoeven wrote:
>
>>> I have observed what appears to be a regression in the ravb ethernet
>driver
>>> caused by d5c3d84657db ("net: phy: Avoid polling PHY with
>>> PHY_IGNORE_INTERRUPTS").
>>>
>>> When booting net-next configured with the ARM64 defconfig on the
>Renesas
>>> r8a7795/salvator-x I see the following and the ravb is unable to
>access the
>>> network. With the above mentioned patch reverted I am able to boot
>to
>>> user-space using nfsroot.
>>
>> The ravb interrupt is connected to a GPIO controller, which is
>> runtime-suspended and thus not serving the interrupt.
OK that makes complete sense then, is your patch going to make it into an
upcoming v4.5-rc pull request or should we think about having the ravb driver
re-assign its phydev->irq to PHY_POLL for the time being?
>>
>> Cfr. "[PATCH/RFC] gpio: rcar: Add Runtime PM handling for interrupts"
>> (http://www.spinics.net/lists/linux-renesas-soc/msg00532.html).
>>
>> I assume it worked before as the PHY driver polled the PHY instead of
>relying
>> solely on the interrupt.
>
> Correct. BTW, I'm going to look at handling AVB_PHY_INT in the ravb
>driver, thus removing the need for routing it to the GPIO controller
>now that
>phylib allows this again...
That sounds like a better solution if the PHY interrupt is consistently and
uniformly available on these boards.
--
Florian
Re: [PATCH v2] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
On Tue, Feb 16, 2016 at 10:55:37AM +0100, Geert Uytterhoeven wrote: > CC Marc > > On Tue, Feb 16, 2016 at 10:43 AM, Dirk Behme wrote: > > Besides the distributor and the CPU interface the GIC-400 additionally > > supports the virtual interface control blocks and the virtual CPU > > interfaces. > > > > Add the physical base addresses and size for these. > > > > See > > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html > > -> 3.2. GIC-400 register map > > > > and Linux kernel's > > > > Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt > > > > for more details. > > > > For the at GICH Virtual interface control blocks at 0xf104 cover the > > whole 128kB (0x2) range. This is done based on the advice from Marc > > Zyngier http://www.spinics.net/lists/arm-kernel/msg483139.html > > > > Signed-off-by: Dirk Behme > > Thanks! > > Acked-by: Geert Uytterhoeven Thanks, I have queued this up for v4.6.
Re: [PATCH v3 04/06] devicetree: bindings: Deprecate property, update example
On Tue, Feb 16, 2016 at 04:17:59PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Deprecate "renesas,channels-mask" and update the r8a7790 CMT example. > > Signed-off-by: Magnus Damm > Acked-by: Geert Uytterhoeven > Acked-by: Laurent Pinchart > Acked-by: Rob Herring Acked-by: Simon Horman
Re: [PATCH v3 06/06] devicetree: bindings: Remove deprecated properties
On Tue, Feb 16, 2016 at 04:18:19PM +0900, Magnus Damm wrote: > From: Magnus Damm > > The deprecated DT properties are part of the GIT history, > no need to keep them around any longer. > > Signed-off-by: Magnus Damm > Acked-by: Rob Herring > Acked-by: Geert Uytterhoeven Acked-by: Simon Horman
Re: [PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings
On Tue, Feb 16, 2016 at 04:18:09PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Remove the 32-bit CMT compat strings to reduce maintenance burden. > > It should be fine to break DT compatibility because the 32-bit > 32-bit CMT DT binding was never part of any upstream DTS file. > > Signed-off-by: Magnus Damm > Acked-by: Rob Herring > Acked-by: Geert Uytterhoeven Acked-by: Simon Horman
Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
On Wed, Feb 17, 2016 at 11:33:27AM +0900, Magnus Damm wrote: > Hi Geert, > > On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven > wrote: > > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm wrote: > >> From: Magnus Damm > >> > >> Add documentation for new separate CMT0 and CMT1 DT compatible strings > >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific > >> features in the driver. The old compat strings will be deprecated in > >> the not so distant future. > >> > >> Signed-off-by: Magnus Damm > >> Acked-by: Geert Uytterhoeven > >> Acked-by: Laurent Pinchart > >> Acked-by: Rob Herring > >> --- > >> > >> Changes since V2: > >> - Added Acked-by from Rob > >> - Removed Tested-by tag from DT binding patch - duh! > >> > >> Changes since V1: > >> - Added Acked-by and Tested-by from Geert > >> - Added Acked-by from Laurent > >> > >> Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt > >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt > >> 2015-09-17 17:26:57.440513000 +0900 > >> @@ -36,6 +36,9 @@ Required Properties: > >> (CMT1 on sh73a0 and r8a7740) > >> This is a fallback for the above renesas,cmt-48-* entries. > >> > >> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car > >> Gen2. > >> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car > >> Gen2. > > > > (advancing a few months always means more comments ;-) > > Indeed! > > > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead? > > I have no strong feelings one way or the other, but I agree that > aiming to make things more consistent must be good. FWIW, I agree with Geert's suggestion. But I also think it is not particularly important. > Your proposal makes the fallback match with what we do for a bunch > other devices on R-Car Gen2 like: > "rcar-gen2-cpg-clocks" > "rcar-gen2-scif" > But we also seem to have: > "pci-rcar-gen2" Bother, it looks like I got pci backwards :( > On R-Car Gen3 we seem to have the following per-SoC compat strings: > "dmac-r8a7795" > "etheravb-r8a7795" > "gpio-r8a7795" > "scif-r8a7795" I believe the above are to follow the existing pattern for per-SoC compat strings in the same driver, which seems sane. > But we also have: > "r8a7795-cpg-mssr" > > My only feeling is that it looks a tad odd if we follow > ",-" for fallback strings but > ",-" for the per-soc binding. Why not > using the same order? Maybe this is specified in some document > somewhere? I believe that the problem is a historical one. Perhaps when we started adding bindings for our hardware there were no clear guidelines. But regardless we ended up with a mix as you describe. In the mean time guidelines have emerged and we (or at least I) have agreed with the device tree people (probably Rob) to use the ,- format for new bindings. My reading is that applies even if it results in fallback and non-fallback bindings for the same driver have different orders. Some precedence for this can now be found in renesas,rcar-dmac.txt. I don't, however, think it applies where we add more soc-specific to a driver that already has such bindings. Or new fallback bindings to a driver that already has such bindings. > I guess your take with "r8a7795-cpg-mssr" above is to follow the same > order as for the fallback case? This seems sane to me, and if so then > perhaps the per-soc compat strings for the CMT should also be updated? > Same for other devices too then, like the recently added > "dmac-r8a7795"? >From my point of view it would be nice to clean things up and re-order all the bindings. But I think the drivers would need to maintain compatibility with the old strings. And I wonder if it is really worth the effort.
Re: [PATCH v3 01/06] devicetree: bindings: Remove sh7372 CMT binding
On Tue, Feb 16, 2016 at 04:17:31PM +0900, Magnus Damm wrote: > From: Magnus Damm > > Remove the sh7372 CMT compat string to reduce maintenance burden. > > It should be fine to break DT compatibility because: > 1) The sh7372 SoC support has been removed from upstream > 2) The sh7372 CMT DT binding was never part of upstream DTS > 3) The CMT driver never matches on the sh7372 binding A trifecta! > > Signed-off-by: Magnus Damm > Acked-by: Geert Uytterhoeven > Acked-by: Laurent Pinchart > Acked-by: Rob Herring I'd like to join this Ack-party! Acked-by: Simon Horman
Re: [PATCH 00/02] arm64: r8a7795 INTC-EX support using RENESAS_IRQC
On Tue, Feb 16, 2016 at 11:26:35AM +0900, Magnus Damm wrote: > arm64: r8a7795 INTC-EX support using RENESAS_IRQC > > [PATCH 01/02] arm64: dts: r8a7795: Add INTC-EX device node > [PATCH 02/02] arm64: renesas: Enable RENESAS_IRQC > > These two patches add the INTC-EX device node to the r8a7795 DTSI > file and selects RENESAS_IRQC to enable the irqchip driver. Those > two together allow r8a7795 based platforms to use external interrupt > pins IRQ0 -> IRQ5. > > The patches in this series can be merged independently in any order, > but for complete run time support the following two patches are also > required: > > [PATCH] pinctrl: sh-pfc: r8a7795: Add support for INTC-EX IRQ pins > [PATCH] clk: shmobile: r8a7795: Add INTC-EX clock > > The DT compat string "renesas,intc-ex-r8a7795" is already included in > Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt > > Tested on r8a7795 Salvator-X by toggling IRQ2 using an external GPIO > connected via a loop back adapter on EXIO_D. > > Signed-off-by: Magnus Damm Thanks, I have queued these up for v4.6.
Re: [PATCH] ARM: dts: r8a7794: replace gpio-key,wakeup with wakeup-source property
On Tue, Feb 16, 2016 at 09:56:54AM +, Sudeep Holla wrote: > > > On 15/02/16 21:48, Simon Horman wrote: > >Though the keyboard driver for GPIO buttons(gpio-keys) will continue to > >check for/support the legacy "gpio-key,wakeup" boolean property to > >enable gpio buttons as wakeup source, "wakeup-source" is the new > >standard binding. > > > >This patch replaces the legacy "gpio-key,wakeup" with the unified > >"wakeup-source" property in order to avoid any futher copy-paste > >duplication. > > > >Changelog text from a similar patch by Sudeep Holla. > > > >Cc: Sudeep Holla > > Thanks for doing this, not sure how I missed it, was this merged in v4.5? I believe it came later and it was my error not to include this in the change that added the nodes in question.
Re: [PATCH v3 0/7] ARM/arm64: dts: renesas: Add/complete L2 cache-controller nodes
On Mon, Feb 15, 2016 at 09:38:28PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series adds the missing L2 cache-controller nodes to the > DTSes for various Renesas ARM-based SoCs, or completes the existing > nodes, and links the CPU nodes to them. > > For R-Mobile APE6 (r8a73a4), the L2 cache-controllers are also linked to > the respective (already existing) SYSC Power Domains. Fortunately these > Power Domains were never powered down, as they are parents of the Power > Domains containing CPU cores. This may change in the future. > > For R-Car Gen2 and Gen3 (r8a779x), this serves as a preparatory step for > adding SYSC Power Domain support later. > > Changes compared to v2: > - Dropped "arm,data-latency" and "arm,tag-latency" properties, as they > may not be valid when using virtualization, > - Dropped already applied parts of "[PATCH v2 6/6] arm64: renesas: > r8a7795: Add L2 cache-controller nodes", > - Changed one-line summary prefix to match current arm-soc practices. > > This series is against renesas-devel-20160215-v4.5-rc4. > It has been tested on r8a73a4/ape6evm, r8a7791/koelsch, r8a7794/alt, and > r8a7795/salvator-x. > > For your convenience, I've also pushed this series to > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#topic/l2-cache-v3 > > Thanks for applying! > > Geert Uytterhoeven (7): > ARM: dts: r8a73a4: Add L2 cache-controller nodes > ARM: dts: r8a7790: Add L2 cache-controller nodes > ARM: dts: r8a7791: Add L2 cache-controller node > ARM: dts: r8a7793: Add L2 cache-controller node > ARM: dts: r8a7794: Add L2 cache-controller node > arm64: dts: r8a7795: Add missing properties to CA57 L2 cache node > arm64: dts: r8a7795: Add CA53 L2 cache-controller node Thanks, I have queued these up for v4.6.
Re: [PATCH v2 5/5] ARM: dts: r8a7794: add sound support
On Fri, Feb 12, 2016 at 10:57:06PM +0300, Sergei Shtylyov wrote:
> On 02/12/2016 10:33 PM, Simon Horman wrote:
>
> >>Sorry for my un-ordered response
> >>
> >>>Define the generic R8A7794 part of the sound device node.
> >>>This sound device is a complex one and comprises the Audio Clock
> >>>Generator
> >>>(ADG), Sampling Rate Converter Unit (SCU), Serial Sound Interface
> >>>[Unit]
> >>>(SSI[U]), and Audio DMAC-Peripheral-Peripheral.
> >>>It is up to the board file to enable the device.
> >>>
> >>>This patch is based on the R8A7791 sound work by Kuninori Morimoto.
> >>>
> >>>Signed-off-by: Sergei Shtylyov
> >>(snip)
> >>>+ rcar_sound,src {
> >>>+ src1: src@1 {
> >>>+ interrupts = >>>IRQ_TYPE_LEVEL_HIGH>;
> >>>+ dmas = <&audma0 0x87>, <&audma0 0x9c>;
> >>>+ dma-names = "rx", "tx";
> >>>+ };
> >>>+ src2: src@2 {
> >>>+ interrupts = >>>IRQ_TYPE_LEVEL_HIGH>;
> >>>+ dmas = <&audma0 0x89>, <&audma0 0x9e>;
> >>>+ dma-names = "rx", "tx";
> >>>+ };
> >>>+ src3: src@3 {
> >>>+ interrupts = >>>IRQ_TYPE_LEVEL_HIGH>;
> >>>+ dmas = <&audma0 0x8b>, <&audma0 0xa0>;
> >>>+ dma-names = "rx", "tx";
> >>>+ };
> >>>+ src4: src@4 {
> >>>+ interrupts = >>>IRQ_TYPE_LEVEL_HIGH>;
> >>>+ dmas = <&audma0 0x8d>, <&audma0 0xb0>;
> >>>+ dma-names = "rx", "tx";
> >>>+ };
> >>>+ src5: src@5 {
> >>>+ interrupts = >>>IRQ_TYPE_LEVEL_HIGH>;
> >>>+ dmas = <&audma0 0x8f>, <&audma0 0xb2>;
> >>>+ dma-names = "rx", "tx";
> >>>+ };
> >>>+ src6: src@6 {
> >>>+ interrupts = >>>IRQ_TYPE_LEVEL_HIGH>;
> >>>+ dmas = <&audma0 0x91>, <&audma0 0xb4>;
> >>>+ dma-names = "rx", "tx";
> >>>+ };
> >>>+ };
> >>
> >>I think this can't work correctly, because driver is assuming
> >>DT has all channles (from 0). (see linux/sound/soc/sh/rcar/src.c ::
> >>rsnd_src_probe)
> >>Can you adds dummy src0 with some comments ? or fix src.c driver ?
> >
> >I would prefer the driver to be fixed (I had a similar patchset locally
> >and I found it doesn't work).
>
> You mean you had R8A7794 sound patch set too?
> >>>
> >>>Yes, I was working on it recently.
> >>>I suppose we should coordinate these things in future to avoid
> >>>duplicated effort.
> >>
> >>Yes, seems a good idea now. :-)
> >>
> >The reason is that DT should describe
> >the hardware rather than the current state of the software.
>
> Yes, of course. Just tell me do I have to fix the driver *before* this
> patch set is accepted?
> >>
> >>>I did not entirely get to the bottom of the problem, but I think that at
> >>>the very least something needs to be done about the for_each_rsnd_src()
> >>>loop in rsnd_src_probe.
> >>
> >>It's not that it replies to my question. :-)
> >>So you're looking at this issue yourself?
> >
> >I have not got very far, as you can see, but I was planning to look into it.
> >I don't mind if you want to do so.
>
>After consultation with the management, I'm going to look into this issue
> myself. :-)
Excellent.
FWIW, I can test anything you come up with for the r8a7794 an alt board
or post patches for it once you have r8a7794/silk sorted out.
> >>>My, obviously not satisfactory, hack around there being no src0 was as
> >>>follows.
> >>>
> >>>diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
> >>>index 68b439ed22d7..58a447b0785b 100644
> >>>--- a/sound/soc/sh/rcar/src.c
> >>>+++ b/sound/soc/sh/rcar/src.c
> >>>@@ -1072,7 +1072,7 @@ int rsnd_src_probe(struct platform_device *pdev,
> >>>
> >>> for_each_rsnd_src(src, priv, i) {
> >>
> >>Which tree is this? The recent devel branch of renesas.git has
> >>for_each_child_of_node() here...
> >
> >renesas-devel-20160118-v4.4
>
>Ah! :-)
>
> >I guess the code in question updated in v4.5-rcX.
>
>Probably...
>
> [...]
>
> MBR, Sergei
Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
Hi Geert, On Tue, Feb 16, 2016 at 10:11 PM, Geert Uytterhoeven wrote: > On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm wrote: >> From: Magnus Damm >> >> Add documentation for new separate CMT0 and CMT1 DT compatible strings >> for R-Car Gen2. These compat strings allow us to enable CMT1-specific >> features in the driver. The old compat strings will be deprecated in >> the not so distant future. >> >> Signed-off-by: Magnus Damm >> Acked-by: Geert Uytterhoeven >> Acked-by: Laurent Pinchart >> Acked-by: Rob Herring >> --- >> >> Changes since V2: >> - Added Acked-by from Rob >> - Removed Tested-by tag from DT binding patch - duh! >> >> Changes since V1: >> - Added Acked-by and Tested-by from Geert >> - Added Acked-by from Laurent >> >> Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++ >> 1 file changed, 3 insertions(+) >> >> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt >> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt >> 2015-09-17 17:26:57.440513000 +0900 >> @@ -36,6 +36,9 @@ Required Properties: >> (CMT1 on sh73a0 and r8a7740) >> This is a fallback for the above renesas,cmt-48-* entries. >> >> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car >> Gen2. >> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car >> Gen2. > > (advancing a few months always means more comments ;-) Indeed! > I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead? I have no strong feelings one way or the other, but I agree that aiming to make things more consistent must be good. Your proposal makes the fallback match with what we do for a bunch other devices on R-Car Gen2 like: "rcar-gen2-cpg-clocks" "rcar-gen2-scif" But we also seem to have: "pci-rcar-gen2" On R-Car Gen3 we seem to have the following per-SoC compat strings: "dmac-r8a7795" "etheravb-r8a7795" "gpio-r8a7795" "scif-r8a7795" But we also have: "r8a7795-cpg-mssr" My only feeling is that it looks a tad odd if we follow ",-" for fallback strings but ",-" for the per-soc binding. Why not using the same order? Maybe this is specified in some document somewhere? I guess your take with "r8a7795-cpg-mssr" above is to follow the same order as for the fallback case? This seems sane to me, and if so then perhaps the per-soc compat strings for the CMT should also be updated? Same for other devices too then, like the recently added "dmac-r8a7795"? Cheers, / magnus
[PATCH v4 2/8] dma-mapping: add {map,unmap}_resource to dma_map_ops
Add methods to handle mapping of device resources from a physical
address. This is needed for example to be able to map MMIO FIFO
registers to a IOMMU.
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
include/linux/dma-mapping.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75857cd..e3aba4e 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -49,6 +49,12 @@ struct dma_map_ops {
struct scatterlist *sg, int nents,
enum dma_data_direction dir,
struct dma_attrs *attrs);
+ dma_addr_t (*map_resource)(struct device *dev, phys_addr_t phys_addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
+ void (*unmap_resource)(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs);
void (*sync_single_for_cpu)(struct device *dev,
dma_addr_t dma_handle, size_t size,
enum dma_data_direction dir);
--
2.7.1
[PATCH v4 0/8] dmaengine: rcar-dmac: add iommu support for slave transfers
Hi,
This series add iommu support to rcar-dmac. It's tested on Koelsch with
CONFIG_IPMMU_VMSA and by enabling the ipmmu_ds node in r8a7791.dtsi. I verified
operation by interacting with /dev/mmcblk1 which is a device behind the iommu.
The series depends on out of tree patch '[PATCH] dmaengine: use phys_addr_t for
slave configuration' which Vinod now have moved forward whit, thanks!
* Changes since v3
- Folded in a fix from Robin to his patch.
- Added a check to make sure dma_map_resource can not be used to map RAM as
pointed out by Robin. I use BUG_ON to enforce this. It might not be the best
method but I saw no other good way since DMA_ERROR_CODE might not be defined
on all platforms.
- Added comment about that DTS changes will disable 2 DMA channels due to a HW
(?) but in the DMAC.
- Dropped the use of dma_attrs, no longer needed.
- Collected Acked-by and Reviewed-by from Laurent.
- Various indentation fix ups.
* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we at that
point can't be sure what direction the mapping is going to be used.
* Changes since v1
- Add and use a dma_{map,unmap}_page_attrs to be able to map the page
using attributes DMA_ATTR_NO_KERNEL_MAPPING and
DMA_ATTR_SKIP_CPU_SYNC. Thanks Laurent.
- Drop check if dmac is part of a iommu group or not, let the DMA
mapping api handle it.
- Move slave configuration data around in rcar-dmac to avoid code
duplication.
- Fix build issue reported by 'kbuild test robot' regarding phys_to_page
not availability on some configurations.
- Add DT information for r8a7791.
* Changes since RFC
- Switch to use the dma-mapping api instead of using the iommu_map()
directly. Turns out the dma-mapper is much smarter then me...
- Dropped the patch to expose domain->ops->pgsize_bitmap from within the
iommu api.
- Dropped the patch showing how I tested the RFC.
Niklas Söderlund (7):
dma-mapping: add {map,unmap}_resource to dma_map_ops
dma-mapping: add dma_{map,unmap}_resource
arm: dma-mapping: add {map,unmap}_resource for iommu ops
dmaengine: rcar-dmac: group slave configuration
dmaengine: rcar-dmac: add iommu support for slave transfers
ARM: dts: r8a7790: add iommus to dmac0 and dmac1
ARM: dts: r8a7791: add iommus to dmac0 and dmac1
Robin Murphy (1):
iommu: Add MMIO mapping type
arch/arm/boot/dts/r8a7790.dtsi | 30
arch/arm/boot/dts/r8a7791.dtsi | 30
arch/arm/mm/dma-mapping.c | 63
drivers/dma/sh/rcar-dmac.c | 81 +-
drivers/iommu/io-pgtable-arm.c | 9 +++--
include/linux/dma-mapping.h| 38
include/linux/iommu.h | 1 +
7 files changed, 233 insertions(+), 19 deletions(-)
--
2.7.1
[PATCH v4 8/8] ARM: dts: r8a7791: add iommus to dmac0 and dmac1
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund
Acked-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 2a369dd..6dff061 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -283,6 +283,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+<&ipmmu_ds 1>,
+<&ipmmu_ds 2>,
+<&ipmmu_ds 3>,
+<&ipmmu_ds 4>,
+<&ipmmu_ds 5>,
+<&ipmmu_ds 6>,
+<&ipmmu_ds 7>,
+<&ipmmu_ds 8>,
+<&ipmmu_ds 9>,
+<&ipmmu_ds 10>,
+<&ipmmu_ds 11>,
+<&ipmmu_ds 12>,
+<&ipmmu_ds 13>,
+<&ipmmu_ds 14>;
};
dmac1: dma-controller@e672 {
@@ -314,6 +329,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+<&ipmmu_ds 16>,
+<&ipmmu_ds 17>,
+<&ipmmu_ds 18>,
+<&ipmmu_ds 19>,
+<&ipmmu_ds 20>,
+<&ipmmu_ds 21>,
+<&ipmmu_ds 22>,
+<&ipmmu_ds 23>,
+<&ipmmu_ds 24>,
+<&ipmmu_ds 25>,
+<&ipmmu_ds 26>,
+<&ipmmu_ds 27>,
+<&ipmmu_ds 28>,
+<&ipmmu_ds 29>;
};
audma0: dma-controller@ec70 {
--
2.7.1
[PATCH v4 3/8] dma-mapping: add dma_{map,unmap}_resource
Map/Unmap a device resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.
Signed-off-by: Niklas Söderlund
---
include/linux/dma-mapping.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index e3aba4e..cc305d1 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -216,6 +216,38 @@ static inline void dma_unmap_page(struct device *dev,
dma_addr_t addr,
debug_dma_unmap_page(dev, addr, size, dir, false);
}
+static inline dma_addr_t dma_map_resource(struct device *dev,
+ phys_addr_t phys_addr,
+ size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+ unsigned long pfn = __phys_to_pfn(phys_addr);
+
+ BUG_ON(!valid_dma_direction(dir));
+
+ /* Don't allow RAM to be mapped */
+ BUG_ON(pfn_valid(pfn));
+
+ if (ops->map_resource)
+ return ops->map_resource(dev, phys_addr, size, dir, attrs);
+
+ return phys_addr;
+}
+
+static inline void dma_unmap_resource(struct device *dev, dma_addr_t addr,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_map_ops *ops = get_dma_ops(dev);
+
+ BUG_ON(!valid_dma_direction(dir));
+ if (ops->unmap_resource)
+ ops->unmap_resource(dev, addr, size, dir, attrs);
+
+}
+
static inline void dma_sync_single_for_cpu(struct device *dev, dma_addr_t addr,
size_t size,
enum dma_data_direction dir)
--
2.7.1
[PATCH v4 4/8] arm: dma-mapping: add {map,unmap}_resource for iommu ops
Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
arch/arm/mm/dma-mapping.c | 63 +++
1 file changed, 63 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0eca381..ae2b175 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1814,6 +1814,63 @@ static void arm_iommu_unmap_page(struct device *dev,
dma_addr_t handle,
__free_iova(mapping, iova, len);
}
+/**
+ * arm_iommu_map_resource - map a device resource for DMA
+ * @dev: valid struct device pointer
+ * @phys_addr: physical address of resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static dma_addr_t arm_iommu_map_resource(struct device *dev,
+ phys_addr_t phys_addr, size_t size,
+ enum dma_data_direction dir, struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t dma_addr;
+ int ret, prot;
+ phys_addr_t addr = phys_addr & PAGE_MASK;
+ int offset = phys_addr & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ dma_addr = __alloc_iova(mapping, size);
+ if (dma_addr == DMA_ERROR_CODE)
+ return dma_addr;
+
+ prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+
+ ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
+ if (ret < 0)
+ goto fail;
+
+ return dma_addr + offset;
+fail:
+ __free_iova(mapping, dma_addr, size);
+ return DMA_ERROR_CODE;
+}
+
+/**
+ * arm_iommu_unmap_resource - unmap a device DMA resource
+ * @dev: valid struct device pointer
+ * @dma_handle: DMA address to resource
+ * @size: size of resource to map
+ * @dir: DMA transfer direction
+ */
+static void arm_iommu_unmap_resource(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+ dma_addr_t iova = dma_handle & PAGE_MASK;
+ int offset = dma_handle & ~PAGE_MASK;
+ int len = PAGE_ALIGN(size + offset);
+
+ if (!iova)
+ return;
+
+ iommu_unmap(mapping->domain, iova, len);
+ __free_iova(mapping, iova, len);
+}
+
static void arm_iommu_sync_single_for_cpu(struct device *dev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
{
@@ -1858,6 +1915,9 @@ struct dma_map_ops iommu_ops = {
.sync_sg_for_cpu= arm_iommu_sync_sg_for_cpu,
.sync_sg_for_device = arm_iommu_sync_sg_for_device,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
@@ -1873,6 +1933,9 @@ struct dma_map_ops iommu_coherent_ops = {
.map_sg = arm_coherent_iommu_map_sg,
.unmap_sg = arm_coherent_iommu_unmap_sg,
+ .map_resource = arm_iommu_map_resource,
+ .unmap_resource = arm_iommu_unmap_resource,
+
.set_dma_mask = arm_dma_set_mask,
};
--
2.7.1
[PATCH v4 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers
Enable slave transfers to devices behind IPMMU:s by mapping the slave
addresses using the dma-mapping API.
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
drivers/dma/sh/rcar-dmac.c | 52 +-
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 743873c..6a24847 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1106,21 +1106,63 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan,
dma_addr_t buf_addr,
return desc;
}
+static int rcar_dmac_set_slave_addr(struct dma_chan *chan,
+struct rcar_dmac_chan_slave *slave,
+phys_addr_t addr, size_t size)
+{
+ enum dma_data_direction dir;
+
+ /*
+* We can't know the direction at this time, see documentation for
+* 'direction' in struct dma_slave_config.
+*/
+ dir = DMA_BIDIRECTIONAL;
+
+ if (slave->xfer_size) {
+ dma_unmap_resource(chan->device->dev, slave->slave_addr,
+ slave->xfer_size, dir, NULL);
+ slave->slave_addr = 0;
+ slave->xfer_size = 0;
+ }
+
+ if (size) {
+ slave->slave_addr = dma_map_resource(chan->device->dev, addr,
+ size, dir, NULL);
+
+ if (dma_mapping_error(chan->device->dev, slave->slave_addr)) {
+ struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+
+ dev_err(chan->device->dev,
+ "chan%u: failed to map %zx@%pap", rchan->index,
+ size, &addr);
+ return -EIO;
+ }
+
+ slave->xfer_size = size;
+ }
+
+ return 0;
+}
+
static int rcar_dmac_device_config(struct dma_chan *chan,
struct dma_slave_config *cfg)
{
struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
+ int ret;
/*
* We could lock this, but you shouldn't be configuring the
* channel, while using it...
*/
- rchan->src.slave_addr = cfg->src_addr;
- rchan->dst.slave_addr = cfg->dst_addr;
- rchan->src.xfer_size = cfg->src_addr_width;
- rchan->dst.xfer_size = cfg->dst_addr_width;
- return 0;
+ ret = rcar_dmac_set_slave_addr(chan, &rchan->src, cfg->src_addr,
+ cfg->src_addr_width);
+ if (ret)
+ return ret;
+
+ ret = rcar_dmac_set_slave_addr(chan, &rchan->dst, cfg->dst_addr,
+ cfg->dst_addr_width);
+ return ret;
}
static int rcar_dmac_chan_terminate_all(struct dma_chan *chan)
--
2.7.1
[PATCH v4 5/8] dmaengine: rcar-dmac: group slave configuration
Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.
Signed-off-by: Niklas Söderlund
Reviewed-by: Laurent Pinchart
---
drivers/dma/sh/rcar-dmac.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
index 7820d07..743873c 100644
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -118,14 +118,21 @@ struct rcar_dmac_desc_page {
sizeof(struct rcar_dmac_xfer_chunk))
/*
+ * @slave_addr: slave memory address
+ * @xfer_size: size (in bytes) of hardware transfers
+ */
+struct rcar_dmac_chan_slave {
+ dma_addr_t slave_addr;
+ unsigned int xfer_size;
+};
+
+/*
* struct rcar_dmac_chan - R-Car Gen2 DMA Controller Channel
* @chan: base DMA channel object
* @iomem: channel I/O memory base
* @index: index of this channel in the controller
- * @src_xfer_size: size (in bytes) of hardware transfers on the source side
- * @dst_xfer_size: size (in bytes) of hardware transfers on the destination
side
- * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
* @mid_rid: hardware MID/RID for the DMA client using this channel
* @lock: protects the channel CHCR register and the desc members
* @desc.free: list of free descriptors
@@ -142,10 +149,8 @@ struct rcar_dmac_chan {
void __iomem *iomem;
unsigned int index;
- unsigned int src_xfer_size;
- unsigned int dst_xfer_size;
- dma_addr_t src_slave_addr;
- dma_addr_t dst_slave_addr;
+ struct rcar_dmac_chan_slave src;
+ struct rcar_dmac_chan_slave dst;
int mid_rid;
spinlock_t lock;
@@ -793,13 +798,13 @@ static void rcar_dmac_chan_configure_desc(struct
rcar_dmac_chan *chan,
case DMA_DEV_TO_MEM:
chcr = RCAR_DMACHCR_DM_INC | RCAR_DMACHCR_SM_FIXED
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->src_xfer_size;
+ xfer_size = chan->src.xfer_size;
break;
case DMA_MEM_TO_DEV:
chcr = RCAR_DMACHCR_DM_FIXED | RCAR_DMACHCR_SM_INC
| RCAR_DMACHCR_RS_DMARS;
- xfer_size = chan->dst_xfer_size;
+ xfer_size = chan->dst.xfer_size;
break;
case DMA_MEM_TO_MEM:
@@ -1038,7 +1043,7 @@ rcar_dmac_prep_slave_sg(struct dma_chan *chan, struct
scatterlist *sgl,
}
dev_addr = dir == DMA_DEV_TO_MEM
-? rchan->src_slave_addr : rchan->dst_slave_addr;
+? rchan->src.slave_addr : rchan->dst.slave_addr;
return rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, false);
}
@@ -1093,7 +1098,7 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan,
dma_addr_t buf_addr,
}
dev_addr = dir == DMA_DEV_TO_MEM
-? rchan->src_slave_addr : rchan->dst_slave_addr;
+? rchan->src.slave_addr : rchan->dst.slave_addr;
desc = rcar_dmac_chan_prep_sg(rchan, sgl, sg_len, dev_addr,
dir, flags, true);
@@ -1110,10 +1115,10 @@ static int rcar_dmac_device_config(struct dma_chan
*chan,
* We could lock this, but you shouldn't be configuring the
* channel, while using it...
*/
- rchan->src_slave_addr = cfg->src_addr;
- rchan->dst_slave_addr = cfg->dst_addr;
- rchan->src_xfer_size = cfg->src_addr_width;
- rchan->dst_xfer_size = cfg->dst_addr_width;
+ rchan->src.slave_addr = cfg->src_addr;
+ rchan->dst.slave_addr = cfg->dst_addr;
+ rchan->src.xfer_size = cfg->src_addr_width;
+ rchan->dst.xfer_size = cfg->dst_addr_width;
return 0;
}
--
2.7.1
Re: [PATCH] dmaengine: use phys_addr_t for slave configuration
On 2016-02-15 23:00:53 +0530, Vinod Koul wrote: > On Tue, Feb 09, 2016 at 11:57:24PM +0100, Wolfram Sang wrote: > > > > > This is a dependency for adding iommu support to the rcar-dmac driver, > > > cfr. > > > "[PATCH v2 0/5] dmaengine: rcar-dmac: add iommu support for slave > > > transfers". > > > http://www.spinics.net/lists/linux-renesas-soc/msg00066.html > > > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg00108.html > > > > > > Thank you for applying! > > > > Yup, we really need it. Anything we can do to help? > > I have done this change and discussing wider changes > I will send CFT hopefully before EOW, pls test :) Thanks Vinod for looking at this!
[PATCH v4 7/8] ARM: dts: r8a7790: add iommus to dmac0 and dmac1
A unconfirmed hardware bug prevents channel 0 and 15 to be used by the
DMAC together with the IPMMU. The DMAC driver will disable the channels
reducing the effective number of channels to 14 per DMAC.
Signed-off-by: Niklas Söderlund
Acked-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7dfd393..048bbf8 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -294,6 +294,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 0>,
+<&ipmmu_ds 1>,
+<&ipmmu_ds 2>,
+<&ipmmu_ds 3>,
+<&ipmmu_ds 4>,
+<&ipmmu_ds 5>,
+<&ipmmu_ds 6>,
+<&ipmmu_ds 7>,
+<&ipmmu_ds 8>,
+<&ipmmu_ds 9>,
+<&ipmmu_ds 10>,
+<&ipmmu_ds 11>,
+<&ipmmu_ds 12>,
+<&ipmmu_ds 13>,
+<&ipmmu_ds 14>;
};
dmac1: dma-controller@e672 {
@@ -325,6 +340,21 @@
power-domains = <&cpg_clocks>;
#dma-cells = <1>;
dma-channels = <15>;
+ iommus = <&ipmmu_ds 15>,
+<&ipmmu_ds 16>,
+<&ipmmu_ds 17>,
+<&ipmmu_ds 18>,
+<&ipmmu_ds 19>,
+<&ipmmu_ds 20>,
+<&ipmmu_ds 21>,
+<&ipmmu_ds 22>,
+<&ipmmu_ds 23>,
+<&ipmmu_ds 24>,
+<&ipmmu_ds 25>,
+<&ipmmu_ds 26>,
+<&ipmmu_ds 27>,
+<&ipmmu_ds 28>,
+<&ipmmu_ds 29>;
};
audma0: dma-controller@ec70 {
--
2.7.1
[PATCH v4 1/8] iommu: Add MMIO mapping type
From: Robin Murphy
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy
Signed-off-by: Niklas Söderlund
---
drivers/iommu/io-pgtable-arm.c | 9 +++--
include/linux/iommu.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 381ca5a..9c19989 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -355,7 +355,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data,
if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
pte |= ARM_LPAE_PTE_AP_RDONLY;
- if (prot & IOMMU_CACHE)
+ if (prot & IOMMU_MMIO)
+ pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
+ << ARM_LPAE_PTE_ATTRINDX_SHIFT);
+ else if (prot & IOMMU_CACHE)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
} else {
@@ -364,7 +367,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data,
pte |= ARM_LPAE_PTE_HAP_READ;
if (prot & IOMMU_WRITE)
pte |= ARM_LPAE_PTE_HAP_WRITE;
- if (prot & IOMMU_CACHE)
+ if (prot & IOMMU_MMIO)
+ pte |= ARM_LPAE_PTE_MEMATTR_DEV;
+ else if (prot & IOMMU_CACHE)
pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
else
pte |= ARM_LPAE_PTE_MEMATTR_NC;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a5c539f..34b6432 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -30,6 +30,7 @@
#define IOMMU_WRITE(1 << 1)
#define IOMMU_CACHE(1 << 2) /* DMA cache coherency */
#define IOMMU_NOEXEC (1 << 3)
+#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
struct iommu_ops;
struct iommu_group;
--
2.7.1
Re: [PATCH 0/2] ravb: fix the fallout of R-Car gen3 gPTP support
From: Sergei Shtylyov
Date: Sat, 06 Feb 2016 17:45:37 +0300
>Here's a set of 2 patches against DaveM's 'net.git' repo fixing up the
> incomplete commit f5d7837f96e5 ("ravb: ptp: Add CONFIG mode support").
> I'm proposing these as fixes but they can be merged as cleanups as well...
>
> [1/2] ravb: kill duplicate setting of CCC.CSEL
> [2/2] ravb: skip gPTP start/stop on R-Car gen3
Series applied, thanks Sergei.
Re: [PATCH 01/16] drm: fixes crct set_mode when crtc mode_fixup is null.
On Tue, Feb 16, 2016 at 08:37:29PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 02/16/2016 05:10 PM, Carlos Palminha wrote:
>
> >This patch set nukes all the dummy crtc mode_fixup implementations.
> >(made on top of Daniel topic/drm-misc branch)
> >
> >Signed-off-by: Carlos Palminha
> >---
> > drivers/gpu/drm/drm_crtc_helper.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> >b/drivers/gpu/drm/drm_crtc_helper.c
> >index e70d064..7539eea 100644
> >--- a/drivers/gpu/drm/drm_crtc_helper.c
> >+++ b/drivers/gpu/drm/drm_crtc_helper.c
> >@@ -343,9 +343,12 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
> > }
> > }
> >
> >-if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
> >-DRM_DEBUG_KMS("CRTC fixup failed\n");
> >-goto done;
> >+if (crtc_funcs->mode_fixup) {
> >+if (!(ret = crtc_funcs->mode_fixup(crtc, mode,
> >+adjusted_mode))) {
>
>You haven't run the patch thru scripts/checkpatch.pl, have you? :-)
> (It curses on assignment inside the *if* expression.)
pre-existing, so checkpatch.pl doesn't get a vote ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 01/16] drm: fixes crct set_mode when crtc mode_fixup is null.
Hello.
On 02/16/2016 05:10 PM, Carlos Palminha wrote:
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/drm_crtc_helper.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index e70d064..7539eea 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -343,9 +343,12 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
}
}
- if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
- DRM_DEBUG_KMS("CRTC fixup failed\n");
- goto done;
+ if (crtc_funcs->mode_fixup) {
+ if (!(ret = crtc_funcs->mode_fixup(crtc, mode,
+ adjusted_mode))) {
You haven't run the patch thru scripts/checkpatch.pl, have you? :-)
(It curses on assignment inside the *if* expression.)
[...]
MBR, Sergei
Re: [PATCH 11/16] drm/atmel-hldcd: removed optional dummy crtc mode_fixup function.
On Tue, 16 Feb 2016 14:19:06 +
Carlos Palminha wrote:
> This patch set nukes all the dummy crtc mode_fixup implementations.
> (made on top of Daniel topic/drm-misc branch)
There's 2 typos in the subject line (s/hldcd/hlcdc/ and
s/removed/remove/), and you're removing an empty line after
atmel_hlcdc_crtc_create() definition (which is correct, but I'm not
sure it should be part of the same patch).
Otherwise it looks good to me.
Once you've fixed those 2 things, you can add my
Acked-by: Boris Brezillon
>
> Signed-off-by: Carlos Palminha
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 9863291..58c4f78 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -121,13 +121,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct
> drm_crtc *c)
> cfg);
> }
>
> -static bool atmel_hlcdc_crtc_mode_fixup(struct drm_crtc *crtc,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - return true;
> -}
> -
> static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
> {
> struct drm_device *dev = c->dev;
> @@ -261,7 +254,6 @@ static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc
> *crtc,
> }
>
> static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
> - .mode_fixup = atmel_hlcdc_crtc_mode_fixup,
> .mode_set = drm_helper_crtc_mode_set,
> .mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
> .mode_set_base = drm_helper_crtc_mode_set_base,
> @@ -349,4 +341,3 @@ fail:
> atmel_hlcdc_crtc_destroy(&crtc->base);
> return ret;
> }
> -
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Re: [PATCH] serial: sh-sci: Remove redundant instances of EARLYCON_DECLARE()
On 02/15/2016 04:36 AM, Geert Uytterhoeven wrote:
> As of commit 2eaa790989e03900 ("earlycon: Use common framework for
> earlycon declarations") it is no longer needer to specify both
> EARLYCON_DECLARE() and OF_EARLYCON_DECLARE().
Reviewed-by: Peter Hurley
Re: [PATCH RESEND 1/3] mmc: sdhi: Add r8a7795 support
On 15 February 2016 at 16:01, Wolfram Sang wrote:
> From: Wolfram Sang
>
> Registers are 64bit apart, so we refactor bus_shift handling a little and set
> it based on the DT compatible. Also, EXT_ACC is different. It has been tested
> on a Salvator-X (Gen3) and, to check for regressions, on a Lager (Gen2).
>
> Signed-off-by: Ai Kyuse
> Signed-off-by: Wolfram Sang
Thanks, applied for next!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
> drivers/mmc/host/Kconfig | 2 +-
> drivers/mmc/host/sh_mobile_sdhi.c | 47
> --
> 3 files changed, 36 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index 400b640fabc768..7fb746dd1a68ca 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -22,6 +22,7 @@ Required properties:
> "renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC
> "renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC
> "renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
> + "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
>
> Optional properties:
> - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 4a35ebf5165d83..d9a9d92fa8379a 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -560,7 +560,7 @@ config MMC_TMIO
>
> config MMC_SDHI
> tristate "SH-Mobile SDHI SD/SDIO controller support"
> - depends on SUPERH || ARM
> + depends on SUPERH || ARM || ARM64
> depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> select MMC_TMIO_CORE
> help
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index 557e2b9dadeec7..9aa147959276d0 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -1,6 +1,8 @@
> /*
> * SuperH Mobile SDHI
> *
> + * Copyright (C) 2016 Sang Engineering, Wolfram Sang
> + * Copyright (C) 2015-16 Renesas Electronics Corporation
> * Copyright (C) 2009 Magnus Damm
> *
> * This program is free software; you can redistribute it and/or modify
> @@ -43,6 +45,7 @@ struct sh_mobile_sdhi_of_data {
> unsigned long capabilities2;
> enum dma_slave_buswidth dma_buswidth;
> dma_addr_t dma_rx_offset;
> + unsigned bus_shift;
> };
>
> static const struct sh_mobile_sdhi_of_data sh_mobile_sdhi_of_cfg[] = {
> @@ -65,6 +68,13 @@ static const struct sh_mobile_sdhi_of_data
> of_rcar_gen2_compatible = {
> .dma_rx_offset = 0x2000,
> };
>
> +static const struct sh_mobile_sdhi_of_data of_rcar_gen3_compatible = {
> + .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_WRPROTECT_DISABLE
> |
> + TMIO_MMC_CLK_ACTUAL | TMIO_MMC_FAST_CLK_CHG,
> + .capabilities = MMC_CAP_SD_HIGHSPEED,
> + .bus_shift = 2,
> +};
> +
> static const struct of_device_id sh_mobile_sdhi_of_match[] = {
> { .compatible = "renesas,sdhi-shmobile" },
> { .compatible = "renesas,sdhi-sh7372" },
> @@ -78,6 +88,7 @@ static const struct of_device_id sh_mobile_sdhi_of_match[]
> = {
> { .compatible = "renesas,sdhi-r8a7792", .data =
> &of_rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7793", .data =
> &of_rcar_gen2_compatible, },
> { .compatible = "renesas,sdhi-r8a7794", .data =
> &of_rcar_gen2_compatible, },
> + { .compatible = "renesas,sdhi-r8a7795", .data =
> &of_rcar_gen3_compatible, },
> {},
> };
> MODULE_DEVICE_TABLE(of, sh_mobile_sdhi_of_match);
> @@ -103,6 +114,15 @@ static void sh_mobile_sdhi_sdbuf_width(struct
> tmio_mmc_host *host, int width)
> case 0xCB0D:
> val = (width == 32) ? 0x : 0x0001;
> break;
> + case 0xCC10: /* Gen3, SD only */
> + case 0xCD10: /* Gen3, SD + MMC */
> + if (width == 64)
> + val = 0x;
> + else if (width == 32)
> + val = 0x0101;
> + else
> + val = 0x0001;
> + break;
> default:
> /* nothing to do */
> return;
> @@ -233,16 +253,26 @@ static int sh_mobile_sdhi_probe(struct platform_device
> *pdev)
> goto eprobe;
> }
>
> + if (of_id && of_id->data) {
> + const struct sh_mobile_sdhi_of_data *of_data = of_id->data;
> +
> + mmc_data->flags |= of_data->tmio_flags;
> + mmc_data->capabilities |= of_data->capabilities;
> + mmc_data->capabilities2 |= of_data->capabilities2;
> + mmc_data->dma_rx_offset = of_data->dma_rx_offset;
> + dma_priv->dma_buswidth = of_data
[PATCH 3/4] drivers: sh: Stop using the legacy clock domain on ARM
Now CONFIG_PM and CONFIG_PM_GENERIC_DOMAINS are enabled unconditionally
for Renesas ARM-based SoCs, the legacy clock domain is no longer used on
these SoCs.
Remove the related support code, and stop entering drivers/sh/ on ARM.
Signed-off-by: Geert Uytterhoeven
---
Notes:
- This does break booting R-Car Gen2 boards using pre-v4.3 DTSes that
don't have power-domains properties,
- This may unbreak SuperH-based ARCH_SHMOBILE platforms, which were
probably broken since v4.4 by commit 0ba58de231066e47 ("drivers: sh:
Get rid of CONFIG_ARCH_SHMOBILE_MULTI").
---
drivers/Makefile| 1 -
drivers/sh/pm_runtime.c | 9 -
2 files changed, 10 deletions(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index 8f5d076baeb0e832..6afdb78e21382538 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -127,7 +127,6 @@ obj-$(CONFIG_SGI_SN)+= sn/
obj-y += firmware/
obj-$(CONFIG_CRYPTO) += crypto/
obj-$(CONFIG_SUPERH) += sh/
-obj-$(CONFIG_ARCH_SHMOBILE)+= sh/
ifndef CONFIG_ARCH_USES_GETTIMEOFFSET
obj-y += clocksource/
endif
diff --git a/drivers/sh/pm_runtime.c b/drivers/sh/pm_runtime.c
index 91a003011acfacb2..c887ecdaf19b7c10 100644
--- a/drivers/sh/pm_runtime.c
+++ b/drivers/sh/pm_runtime.c
@@ -34,15 +34,6 @@ static struct pm_clk_notifier_block platform_bus_notifier = {
static int __init sh_pm_runtime_init(void)
{
- if (IS_ENABLED(CONFIG_ARCH_SHMOBILE)) {
- if (!of_find_compatible_node(NULL, NULL,
-"renesas,cpg-mstp-clocks"))
- return 0;
- if (IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS_OF) &&
- of_find_node_with_property(NULL, "#power-domain-cells"))
- return 0;
- }
-
pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier);
return 0;
}
--
1.9.1
[PATCH 2/4] arm64: renesas: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains
All supported Renesas ARM64 SoCs have clock and power domains. To ensure proper operation of on-SoC modules, module clocks must be ungated, and power domains must be powered up when needed. Currently the user can choose to build a kernel with power management enabled or disabled: - If CONFIG_PM=y, power domains and/or module clocks are handled dynamically by Runtime PM and the generic power domain. - If CONFIG_PM=n, power domains are assumed to be powered up by reset state or by the boot loader, and module clocks are handled by the legacy clock domain on driver (un)bind. The latter is implemented using a platform bus notifier, which applies not only to all on-SoC devices, but to all platform devices present in the system. To remove the dependency on implicit assumptions, and to get rid of the peculiarities of the legacy clock domain, enable CONFIG_PM and CONFIG_PM_GENERIC_DOMAINS unconditionally. Signed-off-by: Geert Uytterhoeven --- arch/arm64/Kconfig.platforms | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 21074f674bdeb707..2c0caac053e8c12a 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -76,7 +76,8 @@ config ARCH_RENESAS bool "Renesas SoC Platforms" select ARCH_SHMOBILE select PINCTRL - select PM_GENERIC_DOMAINS if PM + select PM + select PM_GENERIC_DOMAINS help This enables support for the ARMv8 based Renesas SoCs. -- 1.9.1
[PATCH 4/4] MAINTAINERS: Drop drivers/sh/ for Renesas ARM
None of the code under drivers/sh/ is used anymore on Renesas ARM. Signed-off-by: Geert Uytterhoeven --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index cc2f753cb357a067..a1d03cb4cab49fae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1558,7 +1558,6 @@ F:arch/arm/boot/dts/sh* F: arch/arm/configs/shmobile_defconfig F: arch/arm/include/debug/renesas-scif.S F: arch/arm/mach-shmobile/ -F: drivers/sh/ ARM/SOCFPGA ARCHITECTURE M: Dinh Nguyen -- 1.9.1
[PATCH 0/4] Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains
Hi Simon, Magnus,
All supported Renesas ARM SoCs (except for Emma Mobile EV2) have clock
domains. Some SoCs also have power domains. To ensure proper operation
of on-SoC modules, module clocks must be ungated, and power domains must
be powered up when needed.
Currently the user can choose to build a kernel with power management
enabled or disabled:
- If CONFIG_PM=y, power domains and/or module clocks are handled
dynamically by Runtime PM and the generic power domain.
- If CONFIG_PM=n, power domains are assumed to be powered up by reset
state or by the boot loader, and module clocks are handled by the
legacy clock domain on driver (un)bind.
The latter is implemented using a platform bus notifier, which
applies not only to all on-SoC devices, but to all platform devices
present in the system.
To remove the dependency on implicit assumptions, and to get rid of the
peculiarities of the legacy clock domain, enable CONFIG_PM and
CONFIG_PM_GENERIC_DOMAINS unconditionally, for all Renesas ARM SoCs with
clock and/or power domains.
Patches:
- Patches 1 and 2 enable PM and PM_GENERIC_DOMAINS,
- Patch 3 removes the now unused legacy clock domain code for Renesas
ARM SoCs,
- Patch 4 relieves you from maintaining drivers/sh/, which is no
longer used on Renesas ARM SoCs, and returns it to the SuperH
people.
Notes:
- This does cause an increase in kernel size. Given bloat-o-meter
reports a modest increase of 26 KiB for an RZ/A1H kernel, this
should not be a problem, even when used on RZ/A1H with XIP and
internal RAM only.
- Patch 3 does break booting R-Car Gen2 boards using pre-v4.3 DTSes
that don't have power-domains properties,
- Patch 3 may unbreak SuperH-based ARCH_SHMOBILE platforms, which were
probably broken since v4.4 by commit 0ba58de231066e47 ("drivers: sh:
Get rid of CONFIG_ARCH_SHMOBILE_MULTI"),
- Currently CONFIG_PM=n doesn't work anyway on r8a7795 as "drivers:
sh: Handle PM_GENERIC_DOMAINS_OF=n with new r8a7795 CPG/MSSR
driver" isn't upstream.
For your convenience, I've also pushed this series to
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git#topic/mandatory-pm-v1
Thanks for your comments!
Geert Uytterhoeven (4):
ARM: shmobile: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM
Domains
arm64: renesas: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM
Domains
drivers: sh: Stop using the legacy clock domain on ARM
MAINTAINERS: Drop drivers/sh/ for Renesas ARM
MAINTAINERS| 1 -
arch/arm/mach-shmobile/Kconfig | 13 -
arch/arm64/Kconfig.platforms | 3 ++-
drivers/Makefile | 1 -
drivers/sh/pm_runtime.c| 9 -
5 files changed, 10 insertions(+), 17 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 1/4] ARM: shmobile: Enable PM and PM_GENERIC_DOMAINS for SoCs with PM Domains
All supported Renesas ARM SoCs (except for Emma Mobile EV2) have clock domains. Some SoCs also have power domains. To ensure proper operation of on-SoC modules, module clocks must be ungated, and power domains must be powered up when needed. Currently the user can choose to build a kernel with power management enabled or disabled: - If CONFIG_PM=y, power domains and/or module clocks are handled dynamically by Runtime PM and the generic power domain. - If CONFIG_PM=n, power domains are assumed to be powered up by reset state or by the boot loader, and module clocks are handled by the legacy clock domain on driver (un)bind. The latter is implemented using a platform bus notifier, which applies not only to all on-SoC devices, but to all platform devices present in the system. To remove the dependency on implicit assumptions, and to get rid of the peculiarities of the legacy clock domain, enable CONFIG_PM and CONFIG_PM_GENERIC_DOMAINS unconditionally, for all Renesas ARM SoCs with clock and/or power domains. This does cause an increase in kernel size. Given bloat-o-meter reports a modest increase of 26 KiB for an RZ/A1H kernel, this should not be a problem, even when used on RZ/A1H with XIP and internal RAM only. Signed-off-by: Geert Uytterhoeven --- arch/arm/mach-shmobile/Kconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index cd5f171f83ce6420..2824b81f1a392d87 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -6,28 +6,30 @@ config ARCH_SHMOBILE_MULTI config PM_RCAR bool - select PM_GENERIC_DOMAINS if PM + select PM + select PM_GENERIC_DOMAINS config PM_RMOBILE bool + select PM select PM_GENERIC_DOMAINS config ARCH_RCAR_GEN1 bool - select PM_RCAR if PM || SMP + select PM_RCAR select RENESAS_INTC_IRQPIN select SYS_SUPPORTS_SH_TMU config ARCH_RCAR_GEN2 bool - select PM_RCAR if PM || SMP + select PM_RCAR select RENESAS_IRQC select SYS_SUPPORTS_SH_CMT select PCI_DOMAINS if PCI config ARCH_RMOBILE bool - select PM_RMOBILE if PM + select PM_RMOBILE select SYS_SUPPORTS_SH_CMT select SYS_SUPPORTS_SH_TMU @@ -55,7 +57,8 @@ config ARCH_EMEV2 config ARCH_R7S72100 bool "RZ/A1H (R7S72100)" - select PM_GENERIC_DOMAINS if PM + select PM + select PM_GENERIC_DOMAINS select SYS_SUPPORTS_SH_MTU2 config ARCH_R8A73A4 -- 1.9.1
Re: [PATCH 01/16] drm: fixes crct set_mode when crtc mode_fixup is null.
Thanks!
On 16-02-2016 14:37, Daniel Vetter wrote:
> On Tue, Feb 16, 2016 at 02:10:03PM +, Carlos Palminha wrote:
>> This patch set nukes all the dummy crtc mode_fixup implementations.
>> (made on top of Daniel topic/drm-misc branch)
>>
>> Signed-off-by: Carlos Palminha
>
> Applied this one to drm-misc. I'll let the others hang out there for a bit
> more to collect acks.
>
> Thanks, Daniel
>
>> ---
>> drivers/gpu/drm/drm_crtc_helper.c | 9 ++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
>> b/drivers/gpu/drm/drm_crtc_helper.c
>> index e70d064..7539eea 100644
>> --- a/drivers/gpu/drm/drm_crtc_helper.c
>> +++ b/drivers/gpu/drm/drm_crtc_helper.c
>> @@ -343,9 +343,12 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
>> }
>> }
>>
>> -if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
>> -DRM_DEBUG_KMS("CRTC fixup failed\n");
>> -goto done;
>> +if (crtc_funcs->mode_fixup) {
>> +if (!(ret = crtc_funcs->mode_fixup(crtc, mode,
>> +adjusted_mode))) {
>> +DRM_DEBUG_KMS("CRTC fixup failed\n");
>> +goto done;
>> +}
>> }
>> DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>>
>> --
>> 2.5.0
>>
>
Re: [PATCH 01/16] drm: fixes crct set_mode when crtc mode_fixup is null.
On Tue, Feb 16, 2016 at 02:10:03PM +, Carlos Palminha wrote:
> This patch set nukes all the dummy crtc mode_fixup implementations.
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha
Applied this one to drm-misc. I'll let the others hang out there for a bit
more to collect acks.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_crtc_helper.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> b/drivers/gpu/drm/drm_crtc_helper.c
> index e70d064..7539eea 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -343,9 +343,12 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
> }
> }
>
> - if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
> - DRM_DEBUG_KMS("CRTC fixup failed\n");
> - goto done;
> + if (crtc_funcs->mode_fixup) {
> + if (!(ret = crtc_funcs->mode_fixup(crtc, mode,
> + adjusted_mode))) {
> + DRM_DEBUG_KMS("CRTC fixup failed\n");
> + goto done;
> + }
> }
> DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
>
> --
> 2.5.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 15/16] drm/bochs: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/bochs/bochs_kms.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 2849f1b..c922b48 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -30,13 +30,6 @@ static void bochs_crtc_dpms(struct drm_crtc *crtc, int mode)
}
}
-static bool bochs_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static int bochs_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb)
{
@@ -135,7 +128,6 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
.dpms = bochs_crtc_dpms,
- .mode_fixup = bochs_crtc_mode_fixup,
.mode_set = bochs_crtc_mode_set,
.mode_set_base = bochs_crtc_mode_set_base,
.prepare = bochs_crtc_prepare,
--
2.5.0
[PATCH 14/16] drm/fsl-dcu: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index d8ab8f0..9aa6ad5 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -72,13 +72,6 @@ static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
dev_err(fsl_dev->dev, "Enable CRTC failed\n");
}
-static bool fsl_dcu_drm_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@ -153,7 +146,6 @@ static const struct drm_crtc_helper_funcs
fsl_dcu_drm_crtc_helper_funcs = {
.atomic_flush = fsl_dcu_drm_crtc_atomic_flush,
.disable = fsl_dcu_drm_disable_crtc,
.enable = fsl_dcu_drm_crtc_enable,
- .mode_fixup = fsl_dcu_drm_crtc_mode_fixup,
.mode_set_nofb = fsl_dcu_drm_crtc_mode_set_nofb,
};
--
2.5.0
[PATCH 11/16] drm/atmel-hldcd: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9863291..58c4f78 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -121,13 +121,6 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
*c)
cfg);
}
-static bool atmel_hlcdc_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
{
struct drm_device *dev = c->dev;
@@ -261,7 +254,6 @@ static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc
*crtc,
}
static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
- .mode_fixup = atmel_hlcdc_crtc_mode_fixup,
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
@@ -349,4 +341,3 @@ fail:
atmel_hlcdc_crtc_destroy(&crtc->base);
return ret;
}
-
--
2.5.0
[PATCH 16/16] drm/ast: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/ast/ast_mode.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 0123458..0deeecd 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -497,13 +497,6 @@ static void ast_crtc_dpms(struct drm_crtc *crtc, int mode)
}
}
-static bool ast_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
/* ast is different - we will force move buffers out of VRAM */
static int ast_crtc_do_set_base(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
@@ -617,7 +610,6 @@ static void ast_crtc_commit(struct drm_crtc *crtc)
static const struct drm_crtc_helper_funcs ast_crtc_helper_funcs = {
.dpms = ast_crtc_dpms,
- .mode_fixup = ast_crtc_mode_fixup,
.mode_set = ast_crtc_mode_set,
.mode_set_base = ast_crtc_mode_set_base,
.disable = ast_crtc_disable,
--
2.5.0
[PATCH 10/16] drm/sti: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/sti/sti_crtc.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index de11c7c..e04deed 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -51,14 +51,6 @@ static void sti_crtc_disabling(struct drm_crtc *crtc)
mixer->status = STI_MIXER_DISABLING;
}
-static bool sti_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- /* accept the provided drm_display_mode, do not fix it up */
- return true;
-}
-
static int
sti_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode)
{
@@ -229,7 +221,6 @@ static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
static const struct drm_crtc_helper_funcs sti_crtc_helper_funcs = {
.enable = sti_crtc_enable,
.disable = sti_crtc_disabling,
- .mode_fixup = sti_crtc_mode_fixup,
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = sti_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
--
2.5.0
[PATCH 04/16] drm/udl: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/udl/udl_modeset.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 160ef2a..b87afee 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -279,14 +279,6 @@ static void udl_crtc_dpms(struct drm_crtc *crtc, int mode)
}
-static bool udl_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-
-{
- return true;
-}
-
#if 0
static int
udl_pipe_set_base_atomic(struct drm_crtc *crtc, struct drm_framebuffer *fb,
@@ -402,7 +394,6 @@ static void udl_crtc_commit(struct drm_crtc *crtc)
static const struct drm_crtc_helper_funcs udl_helper_funcs = {
.dpms = udl_crtc_dpms,
- .mode_fixup = udl_crtc_mode_fixup,
.mode_set = udl_crtc_mode_set,
.prepare = udl_crtc_prepare,
.commit = udl_crtc_commit,
--
2.5.0
[PATCH 06/16] drm/rcar-du: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 4ec80ae..627abc80 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -468,14 +468,6 @@ static void rcar_du_crtc_disable(struct drm_crtc *crtc)
rcrtc->outputs = 0;
}
-static bool rcar_du_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- /* TODO Fixup modes */
- return true;
-}
-
static void rcar_du_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
@@ -502,7 +494,6 @@ static void rcar_du_crtc_atomic_flush(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs crtc_helper_funcs = {
- .mode_fixup = rcar_du_crtc_mode_fixup,
.disable = rcar_du_crtc_disable,
.enable = rcar_du_crtc_enable,
.atomic_begin = rcar_du_crtc_atomic_begin,
--
2.5.0
[PATCH 07/16] drm/omapdrm: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index d38fcbc..483acdb 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -330,13 +330,6 @@ static void omap_crtc_destroy(struct drm_crtc *crtc)
kfree(omap_crtc);
}
-static bool omap_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static void omap_crtc_enable(struct drm_crtc *crtc)
{
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
@@ -451,7 +444,6 @@ static const struct drm_crtc_funcs omap_crtc_funcs = {
};
static const struct drm_crtc_helper_funcs omap_crtc_helper_funcs = {
- .mode_fixup = omap_crtc_mode_fixup,
.mode_set_nofb = omap_crtc_mode_set_nofb,
.disable = omap_crtc_disable,
.enable = omap_crtc_enable,
--
2.5.0
[PATCH 12/16] drm/nouveau/dispnv04: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 6f04397..55ccbf0 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -227,13 +227,6 @@ nv_crtc_dpms(struct drm_crtc *crtc, int mode)
NVWriteVgaCrtc(dev, nv_crtc->index, NV_CIO_CRE_RPC1_INDEX, crtc1A);
}
-static bool
-nv_crtc_mode_fixup(struct drm_crtc *crtc, const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static void
nv_crtc_mode_set_vga(struct drm_crtc *crtc, struct drm_display_mode *mode)
{
@@ -1093,7 +1086,6 @@ static const struct drm_crtc_helper_funcs
nv04_crtc_helper_funcs = {
.dpms = nv_crtc_dpms,
.prepare = nv_crtc_prepare,
.commit = nv_crtc_commit,
- .mode_fixup = nv_crtc_mode_fixup,
.mode_set = nv_crtc_mode_set,
.mode_set_base = nv04_crtc_mode_set_base,
.mode_set_base_atomic = nv04_crtc_mode_set_base_atomic,
--
2.5.0
[PATCH 13/16] drm/virtio: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/virtio/virtgpu_display.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index a165f03..6a6cb73 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -237,13 +237,6 @@ virtio_gpu_framebuffer_init(struct drm_device *dev,
return 0;
}
-static bool virtio_gpu_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static void virtio_gpu_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
@@ -277,7 +270,6 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc
*crtc,
static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
.enable= virtio_gpu_crtc_enable,
.disable = virtio_gpu_crtc_disable,
- .mode_fixup= virtio_gpu_crtc_mode_fixup,
.mode_set_nofb = virtio_gpu_crtc_mode_set_nofb,
.atomic_check = virtio_gpu_crtc_atomic_check,
};
--
2.5.0
[PATCH 01/16] drm: fixes crct set_mode when crtc mode_fixup is null.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/drm_crtc_helper.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index e70d064..7539eea 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -343,9 +343,12 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
}
}
- if (!(ret = crtc_funcs->mode_fixup(crtc, mode, adjusted_mode))) {
- DRM_DEBUG_KMS("CRTC fixup failed\n");
- goto done;
+ if (crtc_funcs->mode_fixup) {
+ if (!(ret = crtc_funcs->mode_fixup(crtc, mode,
+ adjusted_mode))) {
+ DRM_DEBUG_KMS("CRTC fixup failed\n");
+ goto done;
+ }
}
DRM_DEBUG_KMS("[CRTC:%d:%s]\n", crtc->base.id, crtc->name);
--
2.5.0
[PATCH 09/16] drm/shmobile: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index 27342fd..88643ab 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -359,13 +359,6 @@ static void shmob_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
scrtc->dpms = mode;
}
-static bool shmob_drm_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static void shmob_drm_crtc_mode_prepare(struct drm_crtc *crtc)
{
shmob_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
@@ -431,7 +424,6 @@ static int shmob_drm_crtc_mode_set_base(struct drm_crtc
*crtc, int x, int y,
static const struct drm_crtc_helper_funcs crtc_helper_funcs = {
.dpms = shmob_drm_crtc_dpms,
- .mode_fixup = shmob_drm_crtc_mode_fixup,
.prepare = shmob_drm_crtc_mode_prepare,
.commit = shmob_drm_crtc_mode_commit,
.mode_set = shmob_drm_crtc_mode_set,
--
2.5.0
[PATCH 05/16] drm/gma: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 13 ++---
drivers/gpu/drm/gma500/gma_display.c | 7 ---
drivers/gpu/drm/gma500/gma_display.h | 3 ---
drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 --
drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 -
drivers/gpu/drm/gma500/psb_intel_display.c | 1 -
6 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 6126546..17db4b4 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -116,7 +116,7 @@ static const struct gma_limit_t cdv_intel_limits[] = {
.p1 = {.min = 1, .max = 10},
.p2 = {.dot_limit = 225000, .p2_slow = 10, .p2_fast = 10},
.find_pll = cdv_intel_find_dp_pll,
-}
+ }
};
#define _wait_for(COND, MS, W) ({ \
@@ -245,7 +245,7 @@ cdv_dpll_set_clock_cdv(struct drm_device *dev, struct
drm_crtc *crtc,
/* We don't know what the other fields of these regs are, so
* leave them in place.
*/
- /*
+ /*
* The BIT 14:13 of 0x8010/0x8030 is used to select the ref clk
* for the pipe A/B. Display spec 1.06 has wrong definition.
* Correct definition is like below:
@@ -256,7 +256,7 @@ cdv_dpll_set_clock_cdv(struct drm_device *dev, struct
drm_crtc *crtc,
*
* if DPLLA sets 01 and DPLLB sets 02, both use clk from DPLLA
*
-*/
+*/
ret = cdv_sb_read(dev, ref_sfr, &ref_value);
if (ret)
return ret;
@@ -646,7 +646,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
* for DP/eDP. When using SSC clock, the ref clk is
100MHz.Otherwise
* it will be 27MHz. From the VBIOS code it seems that the pipe
A choose
* 27MHz for DP/eDP while the Pipe B chooses the 100MHz.
-*/
+*/
if (pipe == 0)
refclk = 27000;
else
@@ -659,7 +659,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
}
drm_mode_debug_printmodeline(adjusted_mode);
-
+
limit = gma_crtc->clock_funcs->limit(crtc, refclk);
ok = limit->find_pll(limit, crtc, adjusted_mode->clock, refclk,
@@ -721,7 +721,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
pipeconf |= PIPE_6BPC;
} else
pipeconf |= PIPE_8BPC;
-
+
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
@@ -974,7 +974,6 @@ struct drm_display_mode *cdv_intel_crtc_mode_get(struct
drm_device *dev,
const struct drm_crtc_helper_funcs cdv_intel_helper_funcs = {
.dpms = gma_crtc_dpms,
- .mode_fixup = gma_crtc_mode_fixup,
.mode_set = cdv_intel_crtc_mode_set,
.mode_set_base = gma_pipe_set_base,
.prepare = gma_crtc_prepare,
diff --git a/drivers/gpu/drm/gma500/gma_display.c
b/drivers/gpu/drm/gma500/gma_display.c
index ff17af4..d6a5c77 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -485,13 +485,6 @@ bool gma_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
}
-bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
void gma_crtc_prepare(struct drm_crtc *crtc)
{
const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
diff --git a/drivers/gpu/drm/gma500/gma_display.h
b/drivers/gpu/drm/gma500/gma_display.h
index ed569d8..fc64241 100644
--- a/drivers/gpu/drm/gma500/gma_display.h
+++ b/drivers/gpu/drm/gma500/gma_display.h
@@ -75,9 +75,6 @@ extern void gma_crtc_load_lut(struct drm_crtc *crtc);
extern void gma_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue, u32 start, u32 size);
extern void gma_crtc_dpms(struct drm_crtc *crtc, int mode);
-extern bool gma_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode);
extern void gma_crtc_prepare(struct drm_crtc *crtc);
extern void gma_crtc_commit(struct drm_crtc *crtc);
extern void gma_crtc_disable(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/gma500/mdfld_intel_display.c
b/drivers/gpu/drm/gma500/mdfld_intel_display.c
index acd3834..92e3f93e 100644
--- a/drivers/gpu/drm/gma500/mdfld_intel_display.c
+++ b/drivers/gpu/drm/gma500/mdfld_intel_display.c
@@ -1026,10 +1026,8 @@ mrst_crtc_mode_set_exit:
const struct drm_crtc_helper_funcs
[PATCH 08/16] drm/msm/mdp: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 8
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 8
2 files changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
index 909d742..38329a6 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
@@ -147,13 +147,6 @@ static void mdp4_crtc_destroy(struct drm_crtc *crtc)
kfree(mdp4_crtc);
}
-static bool mdp4_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
/* statically (for now) map planes to mixer stage (z-order): */
static const int idxs[] = {
[VG1] = 1,
@@ -508,7 +501,6 @@ static const struct drm_crtc_funcs mdp4_crtc_funcs = {
};
static const struct drm_crtc_helper_funcs mdp4_crtc_helper_funcs = {
- .mode_fixup = mdp4_crtc_mode_fixup,
.mode_set_nofb = mdp4_crtc_mode_set_nofb,
.disable = mdp4_crtc_disable,
.enable = mdp4_crtc_enable,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 46682aa..d6b45eb 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -185,13 +185,6 @@ static void mdp5_crtc_destroy(struct drm_crtc *crtc)
kfree(mdp5_crtc);
}
-static bool mdp5_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
/*
* blend_setup() - blend all the planes of a CRTC
*
@@ -634,7 +627,6 @@ static const struct drm_crtc_funcs mdp5_crtc_funcs = {
};
static const struct drm_crtc_helper_funcs mdp5_crtc_helper_funcs = {
- .mode_fixup = mdp5_crtc_mode_fixup,
.mode_set_nofb = mdp5_crtc_mode_set_nofb,
.disable = mdp5_crtc_disable,
.enable = mdp5_crtc_enable,
--
2.5.0
[PATCH 02/16] drm/cirrus: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/cirrus/cirrus_mode.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 4a02854..e7334a8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -91,18 +91,6 @@ static void cirrus_crtc_dpms(struct drm_crtc *crtc, int mode)
WREG_GFX(0xe, gr0e);
}
-/*
- * The core passes the desired mode to the CRTC code to see whether any
- * CRTC-specific modifications need to be made to it. We're in a position
- * to just pass that straight through, so this does nothing
- */
-static bool cirrus_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
static void cirrus_set_start_address(struct drm_crtc *crtc, unsigned offset)
{
struct cirrus_device *cdev = crtc->dev->dev_private;
@@ -372,7 +360,6 @@ static const struct drm_crtc_funcs cirrus_crtc_funcs = {
static const struct drm_crtc_helper_funcs cirrus_helper_funcs = {
.dpms = cirrus_crtc_dpms,
- .mode_fixup = cirrus_crtc_mode_fixup,
.mode_set = cirrus_crtc_mode_set,
.mode_set_base = cirrus_crtc_mode_set_base,
.prepare = cirrus_crtc_prepare,
--
2.5.0
[PATCH 03/16] drm/mgag200: removed optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations.
(made on top of Daniel topic/drm-misc branch)
Signed-off-by: Carlos Palminha
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index dc13c48..aa99c40 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -92,18 +92,6 @@ static inline void mga_wait_busy(struct mga_device *mdev)
} while ((status & 0x01) && time_before(jiffies, timeout));
}
-/*
- * The core passes the desired mode to the CRTC code to see whether any
- * CRTC-specific modifications need to be made to it. We're in a position
- * to just pass that straight through, so this does nothing
- */
-static bool mga_crtc_mode_fixup(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
-{
- return true;
-}
-
#define P_ARRAY_SIZE 9
static int mga_g200se_set_plls(struct mga_device *mdev, long clock)
@@ -1410,7 +1398,6 @@ static const struct drm_crtc_funcs mga_crtc_funcs = {
static const struct drm_crtc_helper_funcs mga_helper_funcs = {
.disable = mga_crtc_disable,
.dpms = mga_crtc_dpms,
- .mode_fixup = mga_crtc_mode_fixup,
.mode_set = mga_crtc_mode_set,
.mode_set_base = mga_crtc_mode_set_base,
.prepare = mga_crtc_prepare,
--
2.5.0
[PATCH 00/16] drm crtc cleanup: nuke optional dummy crtc mode_fixup function.
This patch set nukes all the dummy crtc mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Carlos Palminha (16): drm: fixes crct set_mode when crtc mode_fixup is null. drm/cirrus: removed optional dummy crtc mode_fixup function. drm/mgag200: removed optional dummy crtc mode_fixup function. drm/udl: removed optional dummy crtc mode_fixup function. drm/gma: removed optional dummy crtc mode_fixup function. drm/rcar-du: removed optional dummy crtc mode_fixup function. drm/omapdrm: removed optional dummy crtc mode_fixup function. drm/msm/mdp: removed optional dummy crtc mode_fixup function. drm/shmobile: removed optional dummy crtc mode_fixup function. drm/sti: removed optional dummy crtc mode_fixup function. drm/atmel-hldcd: removed optional dummy crtc mode_fixup function. drm/nouveau/dispnv04: removed optional dummy crtc mode_fixup function. drm/virtio: removed optional dummy crtc mode_fixup function. drm/fsl-dcu: removed optional dummy crtc mode_fixup function. drm/bochs: removed optional dummy crtc mode_fixup function. drm/ast: removed optional dummy crtc mode_fixup function. drivers/gpu/drm/ast/ast_mode.c | 8 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 - drivers/gpu/drm/bochs/bochs_kms.c | 8 drivers/gpu/drm/cirrus/cirrus_mode.c | 13 - drivers/gpu/drm/drm_crtc_helper.c | 9 ++--- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 8 drivers/gpu/drm/gma500/cdv_intel_display.c | 13 ++--- drivers/gpu/drm/gma500/gma_display.c | 7 --- drivers/gpu/drm/gma500/gma_display.h | 3 --- drivers/gpu/drm/gma500/mdfld_intel_display.c | 2 -- drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 - drivers/gpu/drm/gma500/psb_intel_display.c | 1 - drivers/gpu/drm/mgag200/mgag200_mode.c | 13 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 8 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 8 drivers/gpu/drm/nouveau/dispnv04/crtc.c| 8 drivers/gpu/drm/omapdrm/omap_crtc.c| 8 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 9 - drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 8 drivers/gpu/drm/sti/sti_crtc.c | 9 - drivers/gpu/drm/udl/udl_modeset.c | 9 - drivers/gpu/drm/virtio/virtgpu_display.c | 8 22 files changed, 12 insertions(+), 158 deletions(-) -- 2.5.0
Re: [PATCH v3 1/8] iommu: Add MMIO mapping type
* Robin Murphy [2016-02-16 12:43:40 +]:
> On 16/02/16 12:06, Niklas Söderlund wrote:
> >Hi Robin,
> >
> >Thanks for your update patch I will include it in my next version. But
> >I'm sorry I do not understand, is your modification an addition or a
> >substitution to your original patch?
>
> Apologies for being confusing - that was a diff on top of the existing
> patch, to be folded in. My original patch was only handling IOMMU_MMIO for
> stage 2 PTEs, so we also need the extra code to handle the different way of
> setting the appropriate memory type in stage 1 PTEs.
That's what I though but wanted to be clear, thanks for clarifying. I
will fold the diff into your patch and keep your SoB line and send it
out with my series, hope that's a OK way for me to handle it.
Once more thanks for your patch and feedback.
>
> Robin.
>
> >* Robin Murphy [2016-02-11 15:57:26 +]:
> >
> >>On 11/02/16 00:02, Laurent Pinchart wrote:
> >>>Hi Niklas,
> >>>
> >>>Thank you for the patch.
> >>>
> >>>On Wednesday 10 February 2016 01:57:51 Niklas Söderlund wrote:
> From: Robin Murphy
>
> On some platforms, MMIO regions might need slightly different treatment
> compared to mapping regular memory; add the notion of MMIO mappings to
> the IOMMU API's memory type flags, so that callers can let the IOMMU
> drivers know to do the right thing.
>
> Signed-off-by: Robin Murphy
> Acked-by: Laurent Pinchart
> >>>
> >>>Answering the question from the cover letter, yes, it's totally fine to
> >>>pick
> >>>the ack, that's actually expected.
> >>>
> ---
> drivers/iommu/io-pgtable-arm.c | 4 +++-
> include/linux/iommu.h | 1 +
> >>>
> >>>You might be asked to split this patch in two.
> >>
> >>Worse than that, you might also be asked to fix it up when the silly author
> >>remembers that he did this on a stage-2-only ARM SMMU, and the attributes
> >>for the stage 1 tables that the IPMMU uses are in a different code path:
> >>
> >>--->8---
> >>diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> >>index 5b5c299..7622c6e 100644
> >>--- a/drivers/iommu/io-pgtable-arm.c
> >>+++ b/drivers/iommu/io-pgtable-arm.c
> >>@@ -354,7 +354,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> >>arm_lpae_io_pgtable *data,
> >> if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
> >> pte |= ARM_LPAE_PTE_AP_RDONLY;
> >>
> >>- if (prot & IOMMU_CACHE)
> >>+ if (prot & IOMMU_MMIO)
> >>+ pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
> >>+ << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> >>+ else if (prot & IOMMU_CACHE)
> >> pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
> >> << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> >> } else {
> >>--->8---
> >>
> >>Sorry for the bother,
> >>Robin.
> >>
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c
> b/drivers/iommu/io-pgtable-arm.c
> index 381ca5a..3ff4f87 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
> if (prot & IOMMU_WRITE)
> pte |= ARM_LPAE_PTE_HAP_WRITE;
> - if (prot & IOMMU_CACHE)
> + if (prot & IOMMU_MMIO)
> + pte |= ARM_LPAE_PTE_MEMATTR_DEV;
> + else if (prot & IOMMU_CACHE)
> pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
> else
> pte |= ARM_LPAE_PTE_MEMATTR_NC;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index a5c539f..34b6432 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -30,6 +30,7 @@
> #define IOMMU_WRITE (1 << 1)
> #define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
> #define IOMMU_NOEXEC(1 << 3)
> +#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
>
> struct iommu_ops;
> struct iommu_group;
> >>>
> >>
> >
>
Re: [PATCH] pinctrl: sh-pfc: r8a7795: Add support for INTC-EX IRQ pins
On Mon, Feb 15, 2016 at 1:17 PM, Magnus Damm wrote:
> From: Magnus Damm
>
> Most pins on the r8a7795 SoC can be configured in GPIO mode for
> interrupt and GPIO functionality, while a couple of them can also
> be routed to the INTC-EX hardware block (formerly known as IRQC).
>
> On r8a7795 the INTC-EX hardware handles pins IRQ0 -> IRQ5 and
> this patch adds support for them to the PFC driver as "intc_ex_irqN".
>
> Tested on r8a7795 Salvator-X with an external loop back adapter on
> EXIO_D that connects pin 9 (IRQ2/GP2_02) and pin 26 (ExA22/GP2_06).
Thanks!
> Signed-off-by: Magnus Damm
Reviewed-by: Geert Uytterhoeven
Will queue for next renesas-drivers and sh-pfc-for-v4.6.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 02/06] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings
On Tue, Feb 16, 2016 at 8:17 AM, Magnus Damm wrote:
> From: Magnus Damm
>
> Add documentation for new separate CMT0 and CMT1 DT compatible strings
> for R-Car Gen2. These compat strings allow us to enable CMT1-specific
> features in the driver. The old compat strings will be deprecated in
> the not so distant future.
>
> Signed-off-by: Magnus Damm
> Acked-by: Geert Uytterhoeven
> Acked-by: Laurent Pinchart
> Acked-by: Rob Herring
> ---
>
> Changes since V2:
> - Added Acked-by from Rob
> - Removed Tested-by tag from DT binding patch - duh!
>
> Changes since V1:
> - Added Acked-by and Tested-by from Geert
> - Added Acked-by from Laurent
>
> Documentation/devicetree/bindings/timer/renesas,cmt.txt |3 +++
> 1 file changed, 3 insertions(+)
>
> --- 0002/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> +++ work/Documentation/devicetree/bindings/timer/renesas,cmt.txt
> 2015-09-17 17:26:57.440513000 +0900
> @@ -36,6 +36,9 @@ Required Properties:
> (CMT1 on sh73a0 and r8a7740)
> This is a fallback for the above renesas,cmt-48-* entries.
>
> +- "renesas,cmt0-rcar-gen2" for 32-bit CMT0 devices included in R-Car
> Gen2.
> +- "renesas,cmt1-rcar-gen2" for 48-bit CMT1 devices included in R-Car
> Gen2.
(advancing a few months always means more comments ;-)
I'm wondering whether we should use e.g. "renesas,rcar-gen2-cmt0" instead?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 1/8] iommu: Add MMIO mapping type
On 16/02/16 12:06, Niklas Söderlund wrote:
Hi Robin,
Thanks for your update patch I will include it in my next version. But
I'm sorry I do not understand, is your modification an addition or a
substitution to your original patch?
Apologies for being confusing - that was a diff on top of the existing
patch, to be folded in. My original patch was only handling IOMMU_MMIO
for stage 2 PTEs, so we also need the extra code to handle the different
way of setting the appropriate memory type in stage 1 PTEs.
Robin.
* Robin Murphy [2016-02-11 15:57:26 +]:
On 11/02/16 00:02, Laurent Pinchart wrote:
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:51 Niklas Söderlund wrote:
From: Robin Murphy
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy
Acked-by: Laurent Pinchart
Answering the question from the cover letter, yes, it's totally fine to pick
the ack, that's actually expected.
---
drivers/iommu/io-pgtable-arm.c | 4 +++-
include/linux/iommu.h | 1 +
You might be asked to split this patch in two.
Worse than that, you might also be asked to fix it up when the silly author
remembers that he did this on a stage-2-only ARM SMMU, and the attributes
for the stage 1 tables that the IPMMU uses are in a different code path:
--->8---
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 5b5c299..7622c6e 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -354,7 +354,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data,
if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
pte |= ARM_LPAE_PTE_AP_RDONLY;
- if (prot & IOMMU_CACHE)
+ if (prot & IOMMU_MMIO)
+ pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
+ << ARM_LPAE_PTE_ATTRINDX_SHIFT);
+ else if (prot & IOMMU_CACHE)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
} else {
--->8---
Sorry for the bother,
Robin.
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 381ca5a..3ff4f87 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
if (prot & IOMMU_WRITE)
pte |= ARM_LPAE_PTE_HAP_WRITE;
- if (prot & IOMMU_CACHE)
+ if (prot & IOMMU_MMIO)
+ pte |= ARM_LPAE_PTE_MEMATTR_DEV;
+ else if (prot & IOMMU_CACHE)
pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
else
pte |= ARM_LPAE_PTE_MEMATTR_NC;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a5c539f..34b6432 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -30,6 +30,7 @@
#define IOMMU_WRITE (1 << 1)
#define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
#define IOMMU_NOEXEC (1 << 3)
+#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
struct iommu_ops;
struct iommu_group;
renesas-drivers-2016-02-16-v4.5-rc4
I've pushed renesas-drivers-2016-02-16-v4.5-rc4 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
This tree is meant to ease development of platform support and drivers for
Renesas ARM ("shmobile") SoCs. It's created by merging (a) the for-next
branches of various subsystem trees and (b) branches with driver code
submitted or planned for submission to maintainers into the development
branch of Simon Horman's renesas.git tree.
Today's version is based on renesas-devel-20160216-v4.5-rc4.
Included branches with driver code:
- sh-pfc-for-v4.6
- clk-shmobile-for-v4.6
- topic/rcar-dmac-residue-v1
- topic/rcar-dmac-hamza-v3
- topic/r8a7795-drivers-sh-v1
-
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/r8a7795-pcie
- topic/ipmmu-multi-arch-v1
- topic/r8a7795-ipmmu-rfc
- topic/l2-cache-v3
- topic/rcar-sysc-pd-rfc-v2
- git://linuxtv.org/pinchartl/media.git#drm/du/vsp1-kms/boards~5
Included fixes:
- gpio: Use kzalloc() to allocate struct gpio_device to fix crash
- [WIP] gpio: rcar: Always keep the device runtime-resumed
Included subsystem trees:
- git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
- git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
- git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
- git://people.freedesktop.org/~airlied/linux#drm-next
- git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
- git://linuxtv.org/mchehab/media-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git#mmc-next
- git://git.linaro.org/people/ulf.hansson/mmc.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
- git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
- git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
- git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git#next
- git://git.infradead.org/users/vkoul/slave-dma.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
-
git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
- git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
- git://git.infradead.org/battery-2.6.git#master
- git://www.linux-watchdog.org/linux-watchdog-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
- git://anongit.freedesktop.org/drm-intel#topic/drm-misc
- git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 05/06] devicetree: bindings: Remove unused 32-bit CMT bindings
Hello. On 2/16/2016 10:18 AM, Magnus Damm wrote: From: Magnus Damm Remove the 32-bit CMT compat strings to reduce maintenance burden. It should be fine to break DT compatibility because the 32-bit 32-bit CMT DT binding was never part of any upstream DTS file. s/32-bit//. Once is enough. :-) Signed-off-by: Magnus Damm Acked-by: Rob Herring Acked-by: Geert Uytterhoeven [...] MBR, Sergei
Re: [PATCH v3 1/8] iommu: Add MMIO mapping type
Hi Robin,
Thanks for your update patch I will include it in my next version. But
I'm sorry I do not understand, is your modification an addition or a
substitution to your original patch?
* Robin Murphy [2016-02-11 15:57:26 +]:
> On 11/02/16 00:02, Laurent Pinchart wrote:
> >Hi Niklas,
> >
> >Thank you for the patch.
> >
> >On Wednesday 10 February 2016 01:57:51 Niklas Söderlund wrote:
> >>From: Robin Murphy
> >>
> >>On some platforms, MMIO regions might need slightly different treatment
> >>compared to mapping regular memory; add the notion of MMIO mappings to
> >>the IOMMU API's memory type flags, so that callers can let the IOMMU
> >>drivers know to do the right thing.
> >>
> >>Signed-off-by: Robin Murphy
> >>Acked-by: Laurent Pinchart
> >
> >Answering the question from the cover letter, yes, it's totally fine to pick
> >the ack, that's actually expected.
> >
> >>---
> >> drivers/iommu/io-pgtable-arm.c | 4 +++-
> >> include/linux/iommu.h | 1 +
> >
> >You might be asked to split this patch in two.
>
> Worse than that, you might also be asked to fix it up when the silly author
> remembers that he did this on a stage-2-only ARM SMMU, and the attributes
> for the stage 1 tables that the IPMMU uses are in a different code path:
>
> --->8---
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 5b5c299..7622c6e 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -354,7 +354,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> arm_lpae_io_pgtable *data,
> if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
> pte |= ARM_LPAE_PTE_AP_RDONLY;
>
> - if (prot & IOMMU_CACHE)
> + if (prot & IOMMU_MMIO)
> + pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
> + << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> + else if (prot & IOMMU_CACHE)
> pte |= (ARM_LPAE_MAIR_ATTR_IDX_CACHE
> << ARM_LPAE_PTE_ATTRINDX_SHIFT);
> } else {
> --->8---
>
> Sorry for the bother,
> Robin.
>
> >> 2 files changed, 4 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> >>index 381ca5a..3ff4f87 100644
> >>--- a/drivers/iommu/io-pgtable-arm.c
> >>+++ b/drivers/iommu/io-pgtable-arm.c
> >>@@ -364,7 +364,9 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
> >>arm_lpae_io_pgtable *data, pte |= ARM_LPAE_PTE_HAP_READ;
> >>if (prot & IOMMU_WRITE)
> >>pte |= ARM_LPAE_PTE_HAP_WRITE;
> >>- if (prot & IOMMU_CACHE)
> >>+ if (prot & IOMMU_MMIO)
> >>+ pte |= ARM_LPAE_PTE_MEMATTR_DEV;
> >>+ else if (prot & IOMMU_CACHE)
> >>pte |= ARM_LPAE_PTE_MEMATTR_OIWB;
> >>else
> >>pte |= ARM_LPAE_PTE_MEMATTR_NC;
> >>diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> >>index a5c539f..34b6432 100644
> >>--- a/include/linux/iommu.h
> >>+++ b/include/linux/iommu.h
> >>@@ -30,6 +30,7 @@
> >> #define IOMMU_WRITE (1 << 1)
> >> #define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
> >> #define IOMMU_NOEXEC (1 << 3)
> >>+#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
> >>
> >> struct iommu_ops;
> >> struct iommu_group;
> >
>
Re: [PATCH 02/02] arm64: renesas: Enable RENESAS_IRQC
On Tue, Feb 16, 2016 at 3:26 AM, Magnus Damm wrote:
> From: Magnus Damm
>
> Select RENESAS_IRQC for Arm64 SoCs from Renesas to enable
> build of drivers/irqchip/irq-renesas-irqc.c.
>
> Signed-off-by: Magnus Damm
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 01/02] arm64: dts: r8a7795: Add INTC-EX device node
On Tue, Feb 16, 2016 at 3:26 AM, Magnus Damm wrote:
> From: Magnus Damm
>
> Add a single r8a7795 INTC-EX device node to support
> external IRQ pins IRQ0 -> IRQ5.
>
> Signed-off-by: Magnus Damm
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: ravb: Possible Regression In "net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS"
Hello.
On 2/16/2016 10:42 AM, Geert Uytterhoeven wrote:
I have observed what appears to be a regression in the ravb ethernet driver
caused by d5c3d84657db ("net: phy: Avoid polling PHY with
PHY_IGNORE_INTERRUPTS").
When booting net-next configured with the ARM64 defconfig on the Renesas
r8a7795/salvator-x I see the following and the ravb is unable to access the
network. With the above mentioned patch reverted I am able to boot to
user-space using nfsroot.
The ravb interrupt is connected to a GPIO controller, which is
runtime-suspended and thus not serving the interrupt.
Cfr. "[PATCH/RFC] gpio: rcar: Add Runtime PM handling for interrupts"
(http://www.spinics.net/lists/linux-renesas-soc/msg00532.html).
I assume it worked before as the PHY driver polled the PHY instead of relying
solely on the interrupt.
Correct. BTW, I'm going to look at handling AVB_PHY_INT in the ravb
driver, thus removing the need for routing it to the GPIO controller now that
phylib allows this again...
Gr{oetje,eeting}s,
Geert
MBR, Sergei
[PATCH -next] gpio: Use kzalloc() to allocate struct gpio_device to fix crash
gpiochip_add_data() allocates the struct gpio_device using kmalloc(),
which doesn't zero the returned memory.
Hence when calling dev_set_name(), it may try to free a bogus old name,
causing a crash:
Unable to handle kernel NULL pointer dereference at virtual address
...
Backtrace:
[] (kfree) from [] (kfree_const+0x28/0x34)
r9:eea77210 r8: r7:0001 r6:eea77008 r5:eea77010 r4:ee13afc0
[] (kfree_const) from []
(kobject_set_name_vargs+0x90/0xa0)
[] (kobject_set_name_vargs) from []
(dev_set_name+0x28/0x30)
r6:eea77008 r5:eea7721c r4:eea77000 r3:1743
[] (dev_set_name) from [] (gpiochip_add_data+0xa8/0x5e4)
r3:1743 r2:0001 r1:c083b195
[] (gpiochip_add_data) from []
(gpio_rcar_probe+0x228/0x344)
r10:ee922e9c r9:ee922e00 r8:001a r7:eea7721c r6:ee90e010 r5:ee922e80
r4:eea77210
[] (gpio_rcar_probe) from []
(platform_drv_probe+0x58/0xa8)
Use kzalloc() instead of kmalloc() to fix this.
See also the comment for device_initialize():
All fields in @dev must be initialized by the caller to 0, except
for those explicitly set to some other value. The simplest
approach is to use kzalloc() to allocate the structure containing
@dev.
Fixes: ff2b135922992756 ("gpio: make the gpiochip a real device")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpio/gpiolib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index aa4a60e19339b8b5..dc49ba3fe5acf089 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -435,7 +435,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
* First: allocate and populate the internal stat container, and
* set up the struct device.
*/
- gdev = kmalloc(sizeof(*gdev), GFP_KERNEL);
+ gdev = kzalloc(sizeof(*gdev), GFP_KERNEL);
if (!gdev)
return -ENOMEM;
gdev->dev.bus = &gpio_bus_type;
--
1.9.1
Re: [PATCH] ARM: dts: r8a7794: replace gpio-key,wakeup with wakeup-source property
On 15/02/16 21:48, Simon Horman wrote: Though the keyboard driver for GPIO buttons(gpio-keys) will continue to check for/support the legacy "gpio-key,wakeup" boolean property to enable gpio buttons as wakeup source, "wakeup-source" is the new standard binding. This patch replaces the legacy "gpio-key,wakeup" with the unified "wakeup-source" property in order to avoid any futher copy-paste duplication. Changelog text from a similar patch by Sudeep Holla. Cc: Sudeep Holla Thanks for doing this, not sure how I missed it, was this merged in v4.5? Acked-by: Sudeep Holla -- Regards, Sudeep
Re: [PATCH v2] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
CC Marc
On Tue, Feb 16, 2016 at 10:43 AM, Dirk Behme wrote:
> Besides the distributor and the CPU interface the GIC-400 additionally
> supports the virtual interface control blocks and the virtual CPU interfaces.
>
> Add the physical base addresses and size for these.
>
> See
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html
> -> 3.2. GIC-400 register map
>
> and Linux kernel's
>
> Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
>
> for more details.
>
> For the at GICH Virtual interface control blocks at 0xf104 cover the
> whole 128kB (0x2) range. This is done based on the advice from Marc
> Zyngier http://www.spinics.net/lists/arm-kernel/msg483139.html
>
> Signed-off-by: Dirk Behme
Thanks!
Acked-by: Geert Uytterhoeven
> ---
> Changes in v2: Extend the GICH size to 128kB.
>
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 8f1ed23..65f9cc8 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -130,7 +130,9 @@
> #address-cells = <0>;
> interrupt-controller;
> reg = <0x0 0xf101 0 0x1000>,
> - <0x0 0xf102 0 0x2000>;
> + <0x0 0xf102 0 0x2000>,
> + <0x0 0xf104 0 0x2>,
> + <0x0 0xf106 0 0x2000>;
> interrupts = (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>;
> };
> --
> 2.5.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 6/7] arm64: dts: r8a7795: Add missing properties to CA57 L2 cache node
On 16.02.2016 10:43, Sudeep Holla wrote:
On 16/02/16 06:40, Dirk Behme wrote:
On 15.02.2016 21:38, Geert Uytterhoeven wrote:
Add the missing "cache-unified" and "cache-level" properties to the
Cortex-A57 cache-controller node.
Signed-off-by: Geert Uytterhoeven
---
v3:
- Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
cache-controller nodes", after dropping the "arm,data-latency" and
"arm,tag-latency" properties.
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5e46e4ff72ad003..c07f4e83b988ba42 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -68,6 +68,8 @@
L2_CA57: cache-controller@0 {
compatible = "cache";
+cache-unified;
+cache-level = <2>;
As this is completely unused on ARMv8 I don't think that we want to have
these unused entries in the DT.
Sudeep: What do you think?
I am fine with that, I don't see any issue having them as they are
static values and highly unlikely to change and hence no threat to
backward compatibility.
The main concern I had with latency values is that it's currently not
used anywhere but if we decide to use say in secure software, having the
untested/early values in DT might cause compatibility issues in future
as they were added much before the actual understanding of it's usage.
So I prefer to defer them until then.
Fine with me, thanks! :)
With this clarification:
Acked-by: Dirk Behme
Thanks again and best regards
Dirk
Re: [PATCH v3 7/7] arm64: dts: r8a7795: Add CA53 L2 cache-controller node
On 16/02/16 07:12, Geert Uytterhoeven wrote: Hi Dirk, On Tue, Feb 16, 2016 at 7:44 AM, Dirk Behme wrote: [...] As we don't have any CA53 in the device tree yet, and it was rejected to add it, I'd think that we don't want these unused entries at the moment. This is a preparatory step for adding the SYSC PM Domains. I'd propose to add the CA53 entries, first. And then add their L2 cache entries. Based on the outcome of the discussion for the CA57 we have to see if we want to add the unused cache-unified and cache-level, then, too. These are specified by ePAPR, as I said before. Remember, DT describes the hardware, not what Linux (or any other OS) is using. I completely agree and I mentioned the same in the other email. -- Regards, Sudeep
[PATCH v2] arm64: dts: r8a7795: Add GIC-400 virtual interfaces
Besides the distributor and the CPU interface the GIC-400 additionally supports the virtual interface control blocks and the virtual CPU interfaces. Add the physical base addresses and size for these. See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0471b/index.html -> 3.2. GIC-400 register map and Linux kernel's Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt for more details. For the at GICH Virtual interface control blocks at 0xf104 cover the whole 128kB (0x2) range. This is done based on the advice from Marc Zyngier http://www.spinics.net/lists/arm-kernel/msg483139.html Signed-off-by: Dirk Behme --- Changes in v2: Extend the GICH size to 128kB. arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index 8f1ed23..65f9cc8 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -130,7 +130,9 @@ #address-cells = <0>; interrupt-controller; reg = <0x0 0xf101 0 0x1000>, - <0x0 0xf102 0 0x2000>; + <0x0 0xf102 0 0x2000>, + <0x0 0xf104 0 0x2>, + <0x0 0xf106 0 0x2000>; interrupts = ; }; -- 2.5.1
Re: [PATCH v3 6/7] arm64: dts: r8a7795: Add missing properties to CA57 L2 cache node
On 16/02/16 06:40, Dirk Behme wrote:
On 15.02.2016 21:38, Geert Uytterhoeven wrote:
Add the missing "cache-unified" and "cache-level" properties to the
Cortex-A57 cache-controller node.
Signed-off-by: Geert Uytterhoeven
---
v3:
- Remaining part of "[PATCH v2 6/6] arm64: renesas: r8a7795: Add L2
cache-controller nodes", after dropping the "arm,data-latency" and
"arm,tag-latency" properties.
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index b5e46e4ff72ad003..c07f4e83b988ba42 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -68,6 +68,8 @@
L2_CA57: cache-controller@0 {
compatible = "cache";
+cache-unified;
+cache-level = <2>;
As this is completely unused on ARMv8 I don't think that we want to have
these unused entries in the DT.
Sudeep: What do you think?
I am fine with that, I don't see any issue having them as they are
static values and highly unlikely to change and hence no threat to
backward compatibility.
The main concern I had with latency values is that it's currently not
used anywhere but if we decide to use say in secure software, having the
untested/early values in DT might cause compatibility issues in future
as they were added much before the actual understanding of it's usage.
So I prefer to defer them until then.
--
Regards,
Sudeep
Re: [PATCH/RFC] gpio: rcar: Add Runtime PM handling for interrupts
Hi Geert,
On 09/02/16 15:19, Geert Uytterhoeven wrote:
> The R-Car GPIO driver handles Runtime PM for requested GPIOs only.
>
> When using a GPIO purely as an interrupt source, no Runtime PM handling
> is done, and the GPIO module's clock may not be enabled.
>
> To fix this:
> - Add .irq_request_resources() and .irq_release_resources() callbacks
> to handle Runtime PM when an interrupt is requested,
I know that when I was looking at runtime-pm support for IRQ chips
(which I have been meaning to get back too), the problem with
irq_request_resources() is that it is called from the context of a
spinlock (in __setup_irq()). You mentioned that you have not seen any
reports of might_sleep_if(), but have you ensured that it is actually
runtime resuming in your testing and you are not getting lucky?
An alternative for you might be to use the
irq_bus_lock/irq_bus_sync_unlock callbacks. See what Grygorii
implemented for OMAP in commit aca82d1cbb49 ("gpio: omap: move pm
runtime in irq_chip.irq_bus_lock/sync_unlock").
As I mentioned I do plan to get back to the series for adding runtime-pm
support for IRQ chips, in the next week or two.
Cheers
Jon
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
Re: [PATCH/RFC v2 05/11] soc: renesas: rcar: Handle clock domain devices in SYSC PM domains
Hi Geert, On Tuesday 16 February 2016 08:30:03 Geert Uytterhoeven wrote: > On Mon, Feb 15, 2016 at 11:08 PM, Laurent Pinchart wrote: > > On Monday 15 February 2016 22:16:54 Geert Uytterhoeven wrote: > >> R-Car H3 contains some hardware modules (e.g. VSP and FCP_V) that are > >> not only located in a power area controlled by the SYSC system > >> controller, but that are also part of the generic CPG/MSSR clock domain. > >> Make sure both are handled by enabling module clock PM when the device > >> for such a hardware module is attached to the SYSC PM Domain. > > > > Can't we specify both power domains in the DT power-domains attribute > > instead ? > > While the DT property is called "power-domains" (plural), only the first > entry is parsed by genpd_dev_pm_attach(). Which makes sense for power areas > (if there are multiple, they are nested), but indeed can cause problems > when mixed with clock domains. > > For R-Mobile, I fixed it in a similar way. Still, shouldn't it be fixed in genpd ? -- Regards, Laurent Pinchart
