* [PATCH v3 3/6] arm: dts: sun8i: a83t: Add the cir pin for the A83T
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
The CIR Pin of the A83T is located at PL12.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a91c..06e96db7c41a 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -617,6 +617,11 @@
interrupt-controller;
#interrupt-cells = <3>;
+ cir_pins: cir-pins at 0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
+
r_rsb_pins: r-rsb-pins {
pins = "PL0", "PL1";
function = "s_rsb";
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new optional property for the base clock
frequency.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..278098987edb 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -11,6 +11,8 @@ Required properties:
Optional properties:
- linux,rc-map-name: see rc.txt file in the same directory.
- resets : phandle + reset specifier pair
+- clock-frequency : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz
+ if missing.
Example:
@@ -18,6 +20,7 @@ ir0: ir at 1c21800 {
compatible = "allwinner,sun4i-a10-ir";
clocks = <&apb0_gates 6>, <&ir0_clk>;
clock-names = "apb", "ir";
+ clock-frequency = <3000000>;
resets = <&apb0_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
This patch updates the sunxi-ir driver to set the base clock frequency from
devicetree.
This is necessary since there are different ir receivers on the
market, that operate with different frequencies. So this value could be
set if the attached ir receiver needs a different base clock frequency,
than the default 8 MHz.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..f500cea228a9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,8 @@
/* CIR_REG register idle threshold */
#define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
-/* Required frequency for IR0 or IR1 clock in CIR mode */
+/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
#define SUNXI_IR_BASE_CLK 8000000
-/* Frequency after IR internal divider */
-#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
/* Idle Threshold in samples */
@@ -122,7 +118,8 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
- rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+ rawir.duration = ((dt & 0x7f) + 1) *
+ ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, &rawir);
}
}
@@ -148,6 +145,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+ u32 b_clk_freq = SUNXI_IR_BASE_CLK;
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +170,9 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
+ /* Base clock frequency (optional) */
+ of_property_read_u32(dn, "clock-frequency", &b_clk_freq);
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,11 +181,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+ ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
}
+ dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
if (clk_prepare_enable(ir->apb_clk)) {
dev_err(dev, "try to enable apb_ir_clk failed\n");
@@ -225,7 +227,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
- ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+ /* Frequency after IR internal divider with sample period in ns */
+ ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 0/6] arm: sunxi: IR support for A83T
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the sunxi A83T ir module and enhances
the sunxi-ir driver. Right now the base clock frequency for the ir driver
is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3
the ir receiver needs, a 3 MHz base clock frequency to work without
problems with this driver.
This patch series adds support for an optinal property that makes it able
to override the default base clock frequency and enables the ir interface
on the a83t and the Bananapi M3.
changes since v2:
* reorder cir pin (alphabetical)
* fix typo in documentation
changes since v1:
* fix typos, reword Documentation
* initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
* change dev_info() to dev_dbg()
* change naming to cir* in dts/dtsi
* Added acked Ackedi-by to related patch
* use whole memory block instead of registers needed + fix for h3/h5
changes since rfc:
* The property is now optinal. If the property is not available in
the dtb the driver uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency
Regards,
Philipp
Philipp Rossak (6):
media: rc: update sunxi-ir driver to get base clock frequency from
devicetree
media: dt: bindings: Update binding documentation for sunxi IR
controller
arm: dts: sun8i: a83t: Add the cir pin for the A83T
arm: dts: sun8i: a83t: Add support for the cir interface
arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
arm: dts: sun8i: h3-h8: ir register size should be the whole memory
block
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
5 files changed, 37 insertions(+), 9 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH] drm/rockchip: analogix_dp: Ensure that the bridge is powered before poking it
From: Andrzej Hajda @ 2017-12-19 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218112831.7990-1-marc.zyngier@arm.com>
On 18.12.2017 12:28, Marc Zyngier wrote:
> Stopping the X display manager on a kevin platform results in the
> following crash:
>
> [ 674.833536] Synchronous External Abort: synchronous external abort (0x96000010) at 0xffff00000c970640
> [ 674.843886] Internal error: : 96000010 [#1] PREEMPT SMP
> [ 674.849744] Modules linked in:
> [ 674.849755] CPU: 1 PID: 86 Comm: kworker/1:1 Not tainted 4.15.0-rc3-00057-gff24f8cf492d-dirty #3
> [ 674.849760] detected fb_set_par error, error code: -16
> [ 674.849761] Hardware name: Google Kevin (DT)
> [ 674.849773] Workqueue: events analogix_dp_psr_work
> [ 674.849778] pstate: 60000005 (nZCv daif -PAN -UAO)
> [ 674.849784] pc : analogix_dp_send_psr_spd+0x8/0x168
> [ 674.849788] lr : analogix_dp_enable_psr+0x54/0x60
> [ 674.849789] sp : ffff000009b2bd60
> [ 674.849790] x29: ffff000009b2bd60 x28: 0000000000000000
> [ 674.849794] x27: ffff000009913d20 x26: ffff00000900fbf0
> [ 674.849797] x25: ffff8000f1b30000 x24: ffff8000f0c21d98
> [ 674.849800] x23: 0000000000000000 x22: ffff8000f7d3aa00
> [ 674.849803] x21: ffff8000f7d36980 x20: ffff8000f0c21c18
> [ 674.849806] x19: ffff8000f0c21db8 x18: 0000000000000001
> [ 674.849809] x17: 0000ffff89f2ed58 x16: ffff000008222908
> [ 674.849812] x15: 0000000000000000 x14: 0000000000000400
> [ 674.849815] x13: 0000000000000400 x12: 0000000000000000
> [ 674.849817] x11: 0000000000001414 x10: 0000000000000a00
> [ 674.849820] x9 : ffff000009b2bbb0 x8 : ffff8000f1b30a60
> [ 674.849823] x7 : 0000000000080000 x6 : 0000000000000001
> [ 674.849826] x5 : 0000000000000010 x4 : 0000000000000007
> [ 674.849829] x3 : 0000000000000002 x2 : ffff00000c970640
> [ 674.849832] x1 : ffff000009b2bd78 x0 : ffff8000f1624018
> [ 674.849836] Process kworker/1:1 (pid: 86, stack limit = 0x0000000083e5f7c3)
> [ 674.849838] Call trace:
> [ 674.849842] analogix_dp_send_psr_spd+0x8/0x168
> [ 674.849844] analogix_dp_psr_work+0x9c/0xa0
> [ 674.849849] process_one_work+0x1cc/0x328
> [ 674.849852] worker_thread+0x50/0x450
> [ 674.849856] kthread+0xf8/0x128
> [ 674.849860] ret_from_fork+0x10/0x18
> [ 674.849864] Code: b9000001 d65f03c0 f9445802 91190042 (b9400042)
>
> Further investigation show that this happens because the the workqueue
> races with the analogix_dp_bridge_disable() call from the core DRM code,
> and end up trying to write to the DP bridge that has already been powered
> down. This result is a very black screen, and a hard reset.
>
> Instead of counting on luck to keep the bridge alive, let's use the
> pm_runtime framework and take a reference on the device when we're about
> to poke it. That is a fairly big hammer, but one that allows the system
> to stay alive across dozens of X start/stop sequences.
Wouldn't be better to cancel the work in analogix_dp_bridge_disable, it
looks safer.
Regards
Andrzej
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 08743ad96cb9..7f2c190f75e7 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -14,6 +14,7 @@
>
> #include <linux/component.h>
> #include <linux/mfd/syscon.h>
> +#include <linux/pm_runtime.h>
> #include <linux/of_device.h>
> #include <linux/of_graph.h>
> #include <linux/regmap.h>
> @@ -113,10 +114,12 @@ static void analogix_dp_psr_work(struct work_struct *work)
> }
>
> mutex_lock(&dp->psr_lock);
> + pm_runtime_get_sync(dp->dev);
> if (dp->psr_state == EDP_VSC_PSR_STATE_ACTIVE)
> analogix_dp_enable_psr(dp->dev);
> else
> analogix_dp_disable_psr(dp->dev);
> + pm_runtime_put_sync(dp->dev);
> mutex_unlock(&dp->psr_lock);
> }
>
>
^ permalink raw reply
* [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-19 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219060918.nr4ojwpmqf6ju6od@sapphire.tkos.co.il>
Hello Baruch,
On Tue, 19 Dec 2017 08:09:18 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Tue, Dec 19, 2017 at 01:43:20AM +0100, Miquel RAYNAL wrote:
> > On Mon, 18 Dec 2017 22:33:24 +0200
> > Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > > > From: Baruch Siach <baruch@tkos.co.il>
> > > >
> > > > Add compatible strings for AP806 and CP110 that are part of the
> > > > Armada 8k/7k line of SoCs.
> > > >
> > > > Add a note on the differences in the size of the control area in
> > > > different bindings. This is an existing difference between the
> > > > Armada 375 binding and the other boards already supported. The
> > > > new AP806 and CP110 bindings are similar to the existing Armada
> > > > 375 in this regard.
> > > >
> > > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > > [<miquel.raynal@free-electrons.com>: reword, additional details]
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > > ---
> > > > .../devicetree/bindings/thermal/armada-thermal.txt | 24
> > > > +++++++++++++++++----- 1 file changed, 19 insertions(+), 5
> > > > deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > index 24aacf8948c5..9b7b2c03cc6f 100644 ---
> > > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > @@ -7,17 +7,31 @@ Required properties:
> > > > marvell,armada375-thermal marvell,armada380-thermal
> > > > marvell,armadaxp-thermal
> > > > + marvell,armada-ap806-thermal
> > > > + marvell,armada-cp110-thermal
> > > >
> > > > - reg: Device's register space.
> > > > Two entries are expected, see the examples
> > > > below.
> > > > - The first one is required for the sensor
> > > > register;
> > > > - the second one is required for the control
> > > > register
> > > > - to be used for sensor initialization (a.k.a.
> > > > calibration).
> > > > + The first one points to the status register
> > > > (4B).
> > > > + The second one points to the control registers
> > > > (8B).
> > > > + Note: with legacy bindings, the second entry
> > > > pointed
> > > > + only to the so called "control MSB" ("control
> > > > 1"), was
> > > > + 4B wide and did not let the possibility to
> > > > reach the
> > > > + "control LSB" ("control 0") register. This is
> > > > only
> > > > + allowed for compatibility reasons in Armada
> > > > + 370/375/38x/XP DT nodes.
> > >
> > > "allowed" is not the right term, IMO. Legacy compatibles MUST
> > > point to the MSB control register to preserve compatibility with
> > > existing DTs.
> > >
> > > The original patch had a list of legacy and non-legacy
> > > compatibles. I think we need to keep them.
> >
> > Maybe I should reword this paragraph because we both agree on the
> > meaning:
> >
> > "
> > Note: Legacy bindings are only supported with Armada 370/375/38x/XP
> > compatibles. The second memory resource entry only points to
> > "control MSB/control 1", is 4 bytes wide and is preventing any
> > access to "control LSB/control 0".
> > "
> >
> > Does this sounds better to you?
>
> I think we need to explicitly list the affected compatible strings.
> Something like:
I thought listing the SoCs directly would have been acceptable
but I am really not against listing them explicitly :)
>
> For backwards compatibility reasons, the compatibles
> marvell,armada370-thermal, marvell,armada380-thermal, and
> marvell,armadaxp-thermal must point to "control MSB/control 1",
> with size of 4. All other compatibles must point to "control
> LSB/control 0" with size of 8.
>
> But I think you are right that we can use the size of the control
> registers to tell whether e.g. marvell,armada380-thermal is of the
> old binding of the new one. So maybe the "allow" language is more
> correct. But let's make it explicit to avoid any doubt. How about:
>
> The compatibles marvell,armada370-thermal,
> marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
> "control MSB/control 1", with size of 4 (deprecated binding), or
> point to "control LSB/control 0" with size of 8 (current binding).
> All other compatibles must point to "control LSB/control 0" with size
> of 8.
This version looks good to me!
Thank you,
Miqu?l
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/3] irqchip: irq-bcm2836: add support for DT interrupt polarity
From: Stefan Wahren @ 2017-12-19 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-1-git-send-email-stefan.wahren@i2se.com>
Hi Marc,
Am 11.12.2017 um 21:39 schrieb Stefan Wahren:
> This patch series implements DT polarity support for the 1st level interrupt
> controller.
>
> Stefan Wahren (3):
> dt-bindings: bcm2836-l1-intc: add interrupt polarity support
> irqchip: irq-bcm2836: add support for DT interrupt polarity
> ARM: dts: bcm283x: Define polarity of per-cpu interrupts
>
> .../interrupt-controller/brcm,bcm2836-l1-intc.txt | 4 +-
> arch/arm/boot/dts/bcm2836.dtsi | 14 +++----
> arch/arm/boot/dts/bcm2837.dtsi | 12 +++---
> arch/arm/boot/dts/bcm283x.dtsi | 1 +
> drivers/irqchip/irq-bcm2836.c | 46 +++++++++++++---------
> 5 files changed, 44 insertions(+), 33 deletions(-)
>
is this series okay?
^ permalink raw reply
* [PATCH V3 1/2] dt-bindings: bcm283x: Fix register ranges of bcm2835-i2s
From: Stefan Wahren @ 2017-12-19 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512818795-1441-2-git-send-email-stefan.wahren@i2se.com>
Am 09.12.2017 um 12:26 schrieb Stefan Wahren:
> Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
> the bcm2835-i2s requires a clock as DT property. Unfortunately
> the necessary DT change has never been applied. While we are at it
> also fix the first PCM register range to cover the PCM_GRAY register.
>
> This patch only fixes the affected dt-bindings.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> ---
> Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt | 4 ++--
> Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt | 9 ++++-----
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
> index baf9b34..b6a8cc0 100644
> --- a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
> @@ -74,8 +74,8 @@ Example:
>
> bcm2835_i2s: i2s at 7e203000 {
> compatible = "brcm,bcm2835-i2s";
> - reg = < 0x7e203000 0x20>,
> - < 0x7e101098 0x02>;
> + reg = < 0x7e203000 0x24>;
> + clocks = <&clocks BCM2835_CLOCK_PCM>;
>
> dmas = <&dma 2>,
> <&dma 3>;
> diff --git a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
> index 65783de..7bb0362 100644
> --- a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
> @@ -2,9 +2,8 @@
>
> Required properties:
> - compatible: "brcm,bcm2835-i2s"
> -- reg: A list of base address and size entries:
> - * The first entry should cover the PCM registers
> - * The second entry should cover the PCM clock registers
> +- reg: Should contain PCM registers location and length.
> +- clocks: the (PCM) clock to use
> - dmas: List of DMA controller phandle and DMA request line ordered pairs.
> - dma-names: Identifier string for each DMA request line in the dmas property.
> These strings correspond 1:1 with the ordered pairs in dmas.
> @@ -16,8 +15,8 @@ Example:
>
> bcm2835_i2s: i2s at 7e203000 {
> compatible = "brcm,bcm2835-i2s";
> - reg = <0x7e203000 0x20>,
> - <0x7e101098 0x02>;
> + reg = <0x7e203000 0x24>;
> + clocks = <&clocks BCM2835_CLOCK_PCM>;
>
> dmas = <&dma 2>,
> <&dma 3>;
gentle ping ...
^ permalink raw reply
* [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
From: Linu Cherian @ 2017-12-19 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7312293d-8897-95d8-9045-9e97a6c150eb@arm.com>
Hi Marc,
On Mon Dec 18, 2017 at 03:39:22PM +0000, Marc Zyngier wrote:
> Thanks for putting me in the loop Robin.
>
> On 18/12/17 14:48, Robin Murphy wrote:
> > On 10/12/17 02:35, Linu Cherian wrote:
> >> Hi,
> >>
> >>
> >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
> >>> This adds a driver for the SMMUv3 PMU into the perf framework.
> >>> It includes an IORT update to support PM Counter Groups.
> >>>
> >>
> >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
> >> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
> >> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
> >> are managed by two independent drivers.
> >>
> >> The problem arises when we want to alloc/free MSIs for these devices
> >> using the APIs, platform_msi_domain_alloc/free_irqs.
> >> Platform bus id being same for these two hardware blocks, they end up sharing the same
> >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
> >> of this shared ITT becomes a problem when they are managed by two independent
> >> drivers.
> >
> > What is the problem exactly? IIRC resizing a possibly-live ITT is a
> > right pain in the bum to do - is it just that?
>
> Understatement of the day! ;-) Yes, it is a massive headache, and will
> either result in a temporary loss of interrupts (at some point you have
> to unmap the ITT), or with spurious interrupts (you generate interrupts
> for all the MSIs you've blackholed when unmapping the ITT).
Just sharing a thought.
If the firmware, through device tree/ACPI
can provide the following input to the ITS driver,
(For example, as part of msi-parent property in device tree)
1. flag indicating the ITT (Device ID) is being shared
2. the maximum number of vectors that are required to be allocated for this ITT
resizing of ITT and the associated complexities could be avoided.
>
> >
> >> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under
> >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors
> >> required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs
> >> function call for all devices that share the platform bus id.
> >
> > I'm not sure how scalable that approach would be, since it's not
> > entirely obvious how to handle PMCGs associated with named components or
> > root complexes (rather than directly with SMMU instances). We certainly
> > don't want to end up spraying similar PMCG DevID logic around all manner
> > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs
> > will be expected to have distinct IDs from their host devices, they
> > could reasonably still overlap with other PMCGs/SMMUs).
> >
> >> Would like to know your expert opinion on what would be the right approach
> >> to handle this case ?
> >
> > My gut feeling says the way to deal with this properly is in the ITS
> > code, but I appreciate that that's a lot easier said than done :/
>
> I can revive the hack I once wrote for that (and that was hoping to
> forever forget), but that's pretty disgusting, and subject to the above
> caveat.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Linu cherian
^ permalink raw reply
* [PATCH 3/3] i2c: mediatek: Enable i2c module clock before i2c registers access.
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Make sure i2c module clock has been enabled before i2c registers
access.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 58d6401..cf23a74 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -861,10 +861,19 @@ static int mtk_i2c_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int mtk_i2c_resume(struct device *dev)
{
+ int ret;
struct mtk_i2c *i2c = dev_get_drvdata(dev);
+ ret = mtk_i2c_clock_enable(i2c);
+ if (ret) {
+ dev_err(dev, "clock enable failed!\n");
+ return ret;
+ }
+
mtk_i2c_init_hw(i2c);
+ mtk_i2c_clock_disable(i2c);
+
return 0;
}
#endif
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/3] i2c: mediatek: Add i2c compatible for MediaTek MT2712
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add i2c compatible for MT2712. Compare to MT8173 i2c controller,
internal divider of i2c source clock need to be configured for
MT2712 i2c speed calculation.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 09d288c..58d6401 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -61,6 +61,7 @@
#define I2C_DMA_HARD_RST 0x0002
#define I2C_DMA_4G_MODE 0x0001
+#define I2C_DEFAULT_CLK_DIV 5
#define I2C_DEFAULT_SPEED 100000 /* hz */
#define MAX_FS_MODE_SPEED 400000
#define MAX_HS_MODE_SPEED 3400000
@@ -127,6 +128,7 @@ enum I2C_REGS_OFFSET {
OFFSET_DEBUGSTAT = 0x64,
OFFSET_DEBUGCTRL = 0x68,
OFFSET_TRANSFER_LEN_AUX = 0x6c,
+ OFFSET_CLOCK_DIV = 0x70,
};
struct mtk_i2c_compatible {
@@ -136,6 +138,7 @@ struct mtk_i2c_compatible {
unsigned char auto_restart: 1;
unsigned char aux_len_reg: 1;
unsigned char support_33bits: 1;
+ unsigned char timing_adjust: 1;
};
struct mtk_i2c {
@@ -176,6 +179,15 @@ struct mtk_i2c {
.max_num_msgs = 255,
};
+static const struct mtk_i2c_compatible mt2712_compat = {
+ .pmic_i2c = 0,
+ .dcm = 1,
+ .auto_restart = 1,
+ .aux_len_reg = 1,
+ .support_33bits = 1,
+ .timing_adjust = 1,
+};
+
static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = &mt6577_i2c_quirks,
.pmic_i2c = 0,
@@ -183,6 +195,7 @@ struct mtk_i2c {
.auto_restart = 0,
.aux_len_reg = 0,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt6589_compat = {
@@ -192,6 +205,7 @@ struct mtk_i2c {
.auto_restart = 0,
.aux_len_reg = 0,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt7622_compat = {
@@ -201,6 +215,7 @@ struct mtk_i2c {
.auto_restart = 1,
.aux_len_reg = 1,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt8173_compat = {
@@ -209,9 +224,11 @@ struct mtk_i2c {
.auto_restart = 1,
.aux_len_reg = 1,
.support_33bits = 1,
+ .timing_adjust = 0,
};
static const struct of_device_id mtk_i2c_of_match[] = {
+ { .compatible = "mediatek,mt2712-i2c", .data = &mt2712_compat },
{ .compatible = "mediatek,mt6577-i2c", .data = &mt6577_compat },
{ .compatible = "mediatek,mt6589-i2c", .data = &mt6589_compat },
{ .compatible = "mediatek,mt7622-i2c", .data = &mt7622_compat },
@@ -271,6 +288,9 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
if (i2c->dev_comp->dcm)
writew(I2C_DCM_DISABLE, i2c->base + OFFSET_DCM_EN);
+ if (i2c->dev_comp->timing_adjust)
+ writew(I2C_DEFAULT_CLK_DIV - 1, i2c->base + OFFSET_CLOCK_DIV);
+
writew(i2c->timing_reg, i2c->base + OFFSET_TIMING);
writew(i2c->high_speed_reg, i2c->base + OFFSET_HS);
@@ -725,10 +745,6 @@ static int mtk_i2c_probe(struct platform_device *pdev)
if (!i2c)
return -ENOMEM;
- ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
- if (ret)
- return -EINVAL;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
i2c->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(i2c->base))
@@ -759,6 +775,13 @@ static int mtk_i2c_probe(struct platform_device *pdev)
i2c->adap.timeout = 2 * HZ;
i2c->adap.retries = 1;
+ ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
+ if (ret)
+ return -EINVAL;
+
+ if (i2c->dev_comp->timing_adjust)
+ i2c->clk_src_div *= I2C_DEFAULT_CLK_DIV;
+
if (i2c->have_pmic && !i2c->dev_comp->pmic_i2c)
return -EINVAL;
--
1.8.1.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: i2c: Add MediaTek MT2712 i2c binding
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add MT2712 i2c binding to binding file. Compare to MT8173 i2c
controller, MT2712 has timing adjust registers which can adjust
the internal divider of i2c source clock, SCL duty cycle, SCL
compare point, start(repeated start) and stop time, SDA change
time.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index ff7bf37..e199695 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -5,6 +5,7 @@ The MediaTek's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: value should be either of the following.
"mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701
+ "mediatek,mt2712-i2c": for MediaTek MT2712
"mediatek,mt6577-i2c": for MediaTek MT6577
"mediatek,mt6589-i2c": for MediaTek MT6589
"mediatek,mt7622-i2c": for MediaTek MT7622
--
1.8.1.1
^ permalink raw reply related
* [PATCH 0/3] Add i2c dt-binding and compatible for Mediatek MT2712
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: linux-arm-kernel
This patch series based on v4.15-rc1, include MT2712 i2c dt-binding, compatible
and i2c module clock enable.
Jun Gao (3):
dt-bindings: i2c: Add MediaTek MT2712 i2c binding
i2c: mediatek: Add i2c compatible for MediaTek MT2712
i2c: mediatek: Enable i2c module clock before i2c registers access.
Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
drivers/i2c/busses/i2c-mt65xx.c | 40 ++++++++++++++++++++---
2 files changed, 37 insertions(+), 4 deletions(-)
--
1.8.1.1
^ permalink raw reply
* [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
From: Linu Cherian @ 2017-12-19 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <999b7132-2de8-2872-1067-fc7e02cbc57a@arm.com>
Hi Robin,
On Mon Dec 18, 2017 at 02:48:14PM +0000, Robin Murphy wrote:
> On 10/12/17 02:35, Linu Cherian wrote:
> >Hi,
> >
> >
> >On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
> >>This adds a driver for the SMMUv3 PMU into the perf framework.
> >>It includes an IORT update to support PM Counter Groups.
> >>
> >
> >In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
> >that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
> >This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
> >are managed by two independent drivers.
> >
> >The problem arises when we want to alloc/free MSIs for these devices
> >using the APIs, platform_msi_domain_alloc/free_irqs.
> >Platform bus id being same for these two hardware blocks, they end up sharing the same
> >ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
> >of this shared ITT becomes a problem when they are managed by two independent
> >drivers.
>
> What is the problem exactly? IIRC resizing a possibly-live ITT is a
> right pain in the bum to do - is it just that?
Yes exactly. Resizing ITT was the problem in sharing.
> >We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under
> >SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors
> >required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs
> >function call for all devices that share the platform bus id.
>
> I'm not sure how scalable that approach would be, since it's not
> entirely obvious how to handle PMCGs associated with named
> components or root complexes (rather than directly with SMMU
> instances). We certainly don't want to end up spraying similar PMCG
> DevID logic around all manner of GPU/accelerator/etc. drivers in
> future (whilst PMCGs for device TLBs will be expected to have
> distinct IDs from their host devices, they could reasonably still
> overlap with other PMCGs/SMMUs).
>
OK.
While trying the above approach, we also felt that the code will become
lot messier than actually thought.
> >Would like to know your expert opinion on what would be the right approach
> >to handle this case ?
>
> My gut feeling says the way to deal with this properly is in the ITS
> code, but I appreciate that that's a lot easier said than done :/
>
Yes Correct.
> Robin.
--
Linu cherian
^ permalink raw reply
* [GIT PULL] TI DaVinci fixes for v4.15
From: Sekhar Nori @ 2017-12-19 6:15 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.15
for you to fetch changes up to 451df7d110b82998c04a80d0de0f1e79aaa7792a:
ARM: davinci: fix mmc entries in dm365's dma_slave_map (2017-12-08 16:12:21 +0530)
----------------------------------------------------------------
DaVinci fixes for v4.15 consiting of fixes to make EDMA and MMC/SD
work on DM365 and a fix for battery voltage monitoring on Lego EV3.
----------------------------------------------------------------
Alejandro Mery (3):
ARM: davinci: Use platform_device_register_full() to create pdev for dm365's eDMA
ARM: davinci: Add dma_mask to dm365's eDMA device
ARM: davinci: fix mmc entries in dm365's dma_slave_map
David Lechner (1):
ARM: dts: da850-lego-ev3: Fix battery voltage gpio
arch/arm/boot/dts/da850-lego-ev3.dts | 4 ++--
arch/arm/mach-davinci/dm365.c | 29 ++++++++++++++++++-----------
2 files changed, 20 insertions(+), 13 deletions(-)
^ permalink raw reply
* [RFC PATCH 5/5] ARM: NOMMU: Support PMSAv8 MPU
From: afzal mohammed @ 2017-12-19 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c64f605-462b-728c-36d7-e8380c3f16db@arm.com>
Hi,
On Mon, Dec 18, 2017 at 11:47:04AM +0000, Vladimir Murzin wrote:
> > Is there a public ARMv8-R architecture reference manual available ?,
> you might get PMSA-v8 related information from Cortex-R52 TRM [1].
>
> [1] https://developer.arm.com/docs/100026/latest/preface
Thanks Vladimir.
Got a ARMv8-R ARM supplement to ARMv8-A ARM,
https://static.docs.arm.com/ddi0568/a/DDI0568A_b_armv8_r_supplement.pdf
> Not sure why it is not there yet
Cortex-R mafia again ;)
afzal
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-19 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218054009.GA6392@dhcp-128-65.nay.redhat.com>
On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> > > On 13 December 2017 at 12:16, AKASHI Takahiro
> > > <takahiro.akashi@linaro.org> wrote:
> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> > > >> <takahiro.akashi@linaro.org> wrote:
> > > >> > Bhupesh, Ard,
> > > >> >
> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> > > >> >> Hi Ard, Akashi
> > > >> >>
> > > >> > (snip)
> > > >> >
> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> > > >> >> identify its own usable memory and exclude, at its boot time, any
> > > >> >> other memory areas that are part of the panicked kernel's memory.
> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> > > >> >> , for details)
> > > >> >
> > > >> > Right.
> > > >> >
> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> > > >> >> with the crashkernel memory range:
> > > >> >>
> > > >> >> /* add linux,usable-memory-range */
> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> > > >> >> address_cells, size_cells);
> > > >> >>
> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> > > >> >> , for details)
> > > >> >>
> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> > > >> >> they are marked as System RAM or as RESERVED. As,
> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> > > >> >>
> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> > > >> >> ACPI memory and crashes while trying to access the same:
> > > >> >>
> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > >> >> -r`.img --reuse-cmdline -d
> > > >> >>
> > > >> >> [snip..]
> > > >> >>
> > > >> >> Reserved memory range
> > > >> >> 000000000e800000-000000002e7fffff (0)
> > > >> >>
> > > >> >> Coredump memory ranges
> > > >> >> 0000000000000000-000000000e7fffff (0)
> > > >> >> 000000002e800000-000000003961ffff (0)
> > > >> >> 0000000039d40000-000000003ed2ffff (0)
> > > >> >> 000000003ed60000-000000003fbfffff (0)
> > > >> >> 0000001040000000-0000001ffbffffff (0)
> > > >> >> 0000002000000000-0000002ffbffffff (0)
> > > >> >> 0000009000000000-0000009ffbffffff (0)
> > > >> >> 000000a000000000-000000affbffffff (0)
> > > >> >>
> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> > > >> >> memory cap'ing passed to the crash kernel inside
> > > >> >> 'arch/arm64/mm/init.c' (see below):
> > > >> >>
> > > >> >> static void __init fdt_enforce_memory_region(void)
> > > >> >> {
> > > >> >> struct memblock_region reg = {
> > > >> >> .size = 0,
> > > >> >> };
> > > >> >>
> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> > > >> >>
> > > >> >> if (reg.size)
> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> > > >> >> comment this out */
> > > >> >> }
> > > >> >
> > > >> > Please just don't do that. It can cause a fatal damage on
> > > >> > memory contents of the *crashed* kernel.
> > > >> >
> > > >> >> 5). Both the above temporary solutions fix the problem.
> > > >> >>
> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> > > >> >> fail.
> > > >> >>
> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> > > >> >> dt node 'linux,usable-memory-range'
> > > >> >
> > > >> > I still don't understand why we need to carry over the information
> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> > > >> > such regions are free to be reused by the kernel after some point of
> > > >> > initialization. Why does crash dump kernel need to know about them?
> > > >> >
> > > >>
> > > >> Not really. According to the UEFI spec, they can be reclaimed after
> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> > > >> no longer needs them. Of course, in order to be able to boot a kexec
> > > >> kernel, those regions needs to be preserved, which is why they are
> > > >> memblock_reserve()'d now.
> > > >
> > > > For my better understandings, who is actually accessing such regions
> > > > during boot time, uefi itself or efistub?
> > > >
> > >
> > > No, only the kernel. This is where the ACPI tables are stored. For
> > > instance, on QEMU we have
> > >
> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> > > 01000013)
> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> > > BXPC 00000001)
> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> > > BXPC 00000001)
> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> > > BXPC 00000001)
> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> > > BXPC 00000001)
> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> > > BXPC 00000001)
> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> > > BXPC 00000001)
> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> > > BXPC 00000001)
> > >
> > > covered by
> > >
> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> > > ...
> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >
> > OK. I mistakenly understood those regions could be freed after exiting
> > UEFI boot services.
> >
> > >
> > > >> So it seems that kexec does not honour the memblock_reserve() table
> > > >> when booting the next kernel.
> > > >
> > > > not really.
> > > >
> > > >> > (In other words, can or should we skip some part of ACPI-related init code
> > > >> > on crash dump kernel?)
> > > >> >
> > > >>
> > > >> I don't think so. And the change to the handling of ACPI reclaim
> > > >> regions only revealed the bug, not created it (given that other
> > > >> memblock_reserve regions may be affected as well)
> > > >
> > > > As whether we should honor such reserved regions over kexec'ing
> > > > depends on each one's specific nature, we will have to take care one-by-one.
> > > > As a matter of fact, no information about "reserved" memblocks is
> > > > exposed to user space (via proc/iomem).
> > > >
> > >
> > > That is why I suggested (somewhere in this thread?) to not expose them
> > > as 'System RAM'. Do you think that could solve this?
> >
> > Memblock-reserv'ing them is necessary to prevent their corruption and
> > marking them under another name in /proc/iomem would also be good in order
> > not to allocate them as part of crash kernel's memory.
> >
> > But I'm not still convinced that we should export them in useable-
> > memory-range to crash dump kernel. They will be accessed through
> > acpi_os_map_memory() and so won't be required to be part of system ram
> > (or memblocks), I guess.
> > -> Bhupesh?
>
> I forgot how arm64 kernel retrieve the memory ranges and initialize
> them. If no "e820" like interfaces shouldn't kernel reinitialize all
> the memory according to the efi memmap? For kdump kernel anything other
> than usable memory (which is from the dt node instead) should be
> reinitialized according to efi passed info, no?
All the regions exported in efi memmap will be added to memblock.memory
in (u)efi_init() and then trimmed down to the exact range specified as
usable-memory-range by fdt_enforce_memory_region().
Now I noticed that the current fdt_enforce_memory_region() may not work well
with multiple entries in usable-memory-range.
> >
> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> > via a kernel command line parameter, "memmap=".
>
> memmap= is only used in old kexec-tools, now we are passing them via
> e820 table.
Thanks. I remember that you have explained it before.
-Takahiro AKASHI
> [snip]
>
> Thanks
> Dave
^ permalink raw reply
* [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-19 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219014320.182d2522@xps13>
Hi Miqu?l,
On Tue, Dec 19, 2017 at 01:43:20AM +0100, Miquel RAYNAL wrote:
> On Mon, 18 Dec 2017 22:33:24 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> > On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > > From: Baruch Siach <baruch@tkos.co.il>
> > >
> > > Add compatible strings for AP806 and CP110 that are part of the
> > > Armada 8k/7k line of SoCs.
> > >
> > > Add a note on the differences in the size of the control area in
> > > different bindings. This is an existing difference between the
> > > Armada 375 binding and the other boards already supported. The new
> > > AP806 and CP110 bindings are similar to the existing Armada 375 in
> > > this regard.
> > >
> > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > [<miquel.raynal@free-electrons.com>: reword, additional details]
> > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > ---
> > > .../devicetree/bindings/thermal/armada-thermal.txt | 24
> > > +++++++++++++++++----- 1 file changed, 19 insertions(+), 5
> > > deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > index 24aacf8948c5..9b7b2c03cc6f 100644 ---
> > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt +++
> > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt @@
> > > -7,17 +7,31 @@ Required properties: marvell,armada375-thermal
> > > marvell,armada380-thermal marvell,armadaxp-thermal
> > > + marvell,armada-ap806-thermal
> > > + marvell,armada-cp110-thermal
> > >
> > > - reg: Device's register space.
> > > Two entries are expected, see the examples below.
> > > - The first one is required for the sensor register;
> > > - the second one is required for the control register
> > > - to be used for sensor initialization (a.k.a.
> > > calibration).
> > > + The first one points to the status register (4B).
> > > + The second one points to the control registers
> > > (8B).
> > > + Note: with legacy bindings, the second entry
> > > pointed
> > > + only to the so called "control MSB" ("control 1"),
> > > was
> > > + 4B wide and did not let the possibility to reach
> > > the
> > > + "control LSB" ("control 0") register. This is only
> > > + allowed for compatibility reasons in Armada
> > > + 370/375/38x/XP DT nodes.
> >
> > "allowed" is not the right term, IMO. Legacy compatibles MUST point
> > to the MSB control register to preserve compatibility with existing
> > DTs.
> >
> > The original patch had a list of legacy and non-legacy compatibles. I
> > think we need to keep them.
>
> Maybe I should reword this paragraph because we both agree on the
> meaning:
>
> "
> Note: Legacy bindings are only supported with Armada 370/375/38x/XP
> compatibles. The second memory resource entry only points to
> "control MSB/control 1", is 4 bytes wide and is preventing any access
> to "control LSB/control 0".
> "
>
> Does this sounds better to you?
I think we need to explicitly list the affected compatible strings. Something
like:
For backwards compatibility reasons, the compatibles
marvell,armada370-thermal, marvell,armada380-thermal, and
marvell,armadaxp-thermal must point to "control MSB/control 1", with size of
4. All other compatibles must point to "control LSB/control 0" with size of
8.
But I think you are right that we can use the size of the control registers to
tell whether e.g. marvell,armada380-thermal is of the old binding of the new
one. So maybe the "allow" language is more correct. But let's make it explicit
to avoid any doubt. How about:
The compatibles marvell,armada370-thermal, marvell,armada380-thermal, and
marvell,armadaxp-thermal must point to "control MSB/control 1", with size of
4 (deprecated binding), or point to "control LSB/control 0" with size of 8
(current binding). All other compatibles must point to "control LSB/control
0" with size of 8.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Baruch Siach @ 2017-12-19 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219013233.319365c4@xps13>
Hi Miqu?l,
On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> On Mon, 18 Dec 2017 22:35:42 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> > > Bindings were incomplete for a long time by only exposing one of
> > > the two available control registers. To ease the migration to the
> > > full bindings (already in use for the Armada 375 SoC), rename the
> > > pointers for clarification. This way, it will only be needed to add
> > > another pointer to access the other control register when the time
> > > comes.
> > >
> > > This avoids dangerous situations where the offset 0 of the control
> > > area can be either one register or the other depending on the
> > > bindings used. After this change, device trees of other SoCs could
> > > be migrated to the "full" bindings if they may benefit from
> > > features from the unaccessible register, without any change in the
> > > driver.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > > ---
> >
> > [...]
> >
> > > + /*
> > > + * Legacy DT bindings only described "control1" register
> > > (also referred
> > > + * as "control MSB" on old documentation). New bindings
> > > cover
> > > + * "control0/control LSB" and "control1/control MSB"
> > > registers within
> > > + * the same resource, which is then of size 8 instead of 4.
> > > + */
> > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > + /* ->control0 unavailable in this configuration */
> > > + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > > + } else {
> > > + priv->control0 = control + CONTROL0_OFFSET;
> > > + priv->control1 = control + CONTROL1_OFFSET;
> > > + }
> >
> > The needs_control0 field that you mentioned in the cover page is
> > missing here.
>
> Yes, at this point nobody actually *needs* control0 so the limitation
> is added with the patch that introduce ap806 support as it is the first
> compatible that needs both control0 and control1 to work correctly.
> Does this bother you?
No. It is just that we agreed to have a verification here that the size of the
control registers resource matches the binding. I thought that the
needs_control0 field that you mention in the cover page is meant to implement
that. But I'm not sure all that is strictly necessary. It would just make sure
that no one introduces a DT with the wrong resource size.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH V4 26/26] PCI: Remove pci_get_bus_and_slot() function
From: Sinan Kaya @ 2017-12-19 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Now that all users of pci_get_bus_and_slot() switched to
pci_get_domain_bus_and_slot(), it is now safe to remove this function.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
include/linux/pci.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 66cca1c..04cecbe 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -948,11 +948,6 @@ struct pci_dev *pci_get_subsys(unsigned int vendor, unsigned int device,
struct pci_dev *pci_get_slot(struct pci_bus *bus, unsigned int devfn);
struct pci_dev *pci_get_domain_bus_and_slot(int domain, unsigned int bus,
unsigned int devfn);
-static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
- unsigned int devfn)
-{
- return pci_get_domain_bus_and_slot(0, bus, devfn);
-}
struct pci_dev *pci_get_class(unsigned int class, struct pci_dev *from);
int pci_dev_present(const struct pci_device_id *ids);
@@ -1660,9 +1655,6 @@ static inline struct pci_bus *pci_find_next_bus(const struct pci_bus *from)
static inline struct pci_dev *pci_get_slot(struct pci_bus *bus,
unsigned int devfn)
{ return NULL; }
-static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
- unsigned int devfn)
-{ return NULL; }
static inline struct pci_dev *pci_get_domain_bus_and_slot(int domain,
unsigned int bus, unsigned int devfn)
{ return NULL; }
--
1.9.1
^ permalink raw reply related
* [PATCH V4 25/26] i7300_idle: remove unused file
From: Sinan Kaya @ 2017-12-19 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
i7300_idle.h is not being called by any source file and contains calls to
pci_get_bus_and_slot() that we are trying to deprecate. Remove unused file.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
include/linux/i7300_idle.h | 84 ----------------------------------------------
1 file changed, 84 deletions(-)
delete mode 100644 include/linux/i7300_idle.h
diff --git a/include/linux/i7300_idle.h b/include/linux/i7300_idle.h
deleted file mode 100644
index 4dbe651..0000000
--- a/include/linux/i7300_idle.h
+++ /dev/null
@@ -1,84 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-#ifndef I7300_IDLE_H
-#define I7300_IDLE_H
-
-#include <linux/pci.h>
-
-/*
- * I/O AT controls (PCI bus 0 device 8 function 0)
- * DIMM controls (PCI bus 0 device 16 function 1)
- */
-#define IOAT_BUS 0
-#define IOAT_DEVFN PCI_DEVFN(8, 0)
-#define MEMCTL_BUS 0
-#define MEMCTL_DEVFN PCI_DEVFN(16, 1)
-
-struct fbd_ioat {
- unsigned int vendor;
- unsigned int ioat_dev;
- unsigned int enabled;
-};
-
-/*
- * The i5000 chip-set has the same hooks as the i7300
- * but it is not enabled by default and must be manually
- * manually enabled with "forceload=1" because it is
- * only lightly validated.
- */
-
-static const struct fbd_ioat fbd_ioat_list[] = {
- {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_CNB, 1},
- {PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT, 0},
- {0, 0}
-};
-
-/* table of devices that work with this driver */
-static const struct pci_device_id pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_FBD_CNB) },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_5000_ERR) },
- { } /* Terminating entry */
-};
-
-/* Check for known platforms with I/O-AT */
-static inline int i7300_idle_platform_probe(struct pci_dev **fbd_dev,
- struct pci_dev **ioat_dev,
- int enable_all)
-{
- int i;
- struct pci_dev *memdev, *dmadev;
-
- memdev = pci_get_bus_and_slot(MEMCTL_BUS, MEMCTL_DEVFN);
- if (!memdev)
- return -ENODEV;
-
- for (i = 0; pci_tbl[i].vendor != 0; i++) {
- if (memdev->vendor == pci_tbl[i].vendor &&
- memdev->device == pci_tbl[i].device) {
- break;
- }
- }
- if (pci_tbl[i].vendor == 0)
- return -ENODEV;
-
- dmadev = pci_get_bus_and_slot(IOAT_BUS, IOAT_DEVFN);
- if (!dmadev)
- return -ENODEV;
-
- for (i = 0; fbd_ioat_list[i].vendor != 0; i++) {
- if (dmadev->vendor == fbd_ioat_list[i].vendor &&
- dmadev->device == fbd_ioat_list[i].ioat_dev) {
- if (!(fbd_ioat_list[i].enabled || enable_all))
- continue;
- if (fbd_dev)
- *fbd_dev = memdev;
- if (ioat_dev)
- *ioat_dev = dmadev;
-
- return 0;
- }
- }
- return -ENODEV;
-}
-
-#endif
--
1.9.1
^ permalink raw reply related
* [PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
struct riva_par has a pointer to struct pci_dev. Use the pci_dev member
to extract the domain information.
Change the function signature for CalcStateExt and RivaGetConfig to pass
in struct pci_dev in addition to RIVA_HW_INST so that code inside the
riva_hw.c can also calculate domain number and pass it to
pci_get_domain_bus_and_slot().
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/riva/fbdev.c | 2 +-
drivers/video/fbdev/riva/nv_driver.c | 7 ++++---
drivers/video/fbdev/riva/riva_hw.c | 20 +++++++++++++-------
drivers/video/fbdev/riva/riva_hw.h | 3 ++-
4 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/riva/fbdev.c b/drivers/video/fbdev/riva/fbdev.c
index 1ea78bb..ff82823 100644
--- a/drivers/video/fbdev/riva/fbdev.c
+++ b/drivers/video/fbdev/riva/fbdev.c
@@ -780,7 +780,7 @@ static int riva_load_video_mode(struct fb_info *info)
else
newmode.misc_output |= 0x80;
- rc = CalcStateExt(&par->riva, &newmode.ext, bpp, width,
+ rc = CalcStateExt(&par->riva, &newmode.ext, par->pdev, bpp, width,
hDisplaySize, height, dotClock);
if (rc)
goto out;
diff --git a/drivers/video/fbdev/riva/nv_driver.c b/drivers/video/fbdev/riva/nv_driver.c
index f3694cf..a3d9c66 100644
--- a/drivers/video/fbdev/riva/nv_driver.c
+++ b/drivers/video/fbdev/riva/nv_driver.c
@@ -159,6 +159,7 @@ unsigned long riva_get_memlen(struct riva_par *par)
unsigned int chipset = par->Chipset;
struct pci_dev* dev;
u32 amt;
+ int domain = pci_domain_nr(par->pdev->bus);
switch (chip->Architecture) {
case NV_ARCH_03:
@@ -226,12 +227,12 @@ unsigned long riva_get_memlen(struct riva_par *par)
case NV_ARCH_30:
if(chipset == NV_CHIP_IGEFORCE2) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &amt);
pci_dev_put(dev);
memlen = (((amt >> 6) & 31) + 1) * 1024;
} else if (chipset == NV_CHIP_0x01F0) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x84, &amt);
pci_dev_put(dev);
memlen = (((amt >> 4) & 127) + 1) * 1024;
@@ -417,6 +418,6 @@ unsigned long riva_get_maxdclk(struct riva_par *par)
}
par->riva.flatPanel = (par->FlatPanel > 0) ? TRUE : FALSE;
- RivaGetConfig(&par->riva, par->Chipset);
+ RivaGetConfig(&par->riva, par->pdev, par->Chipset);
}
diff --git a/drivers/video/fbdev/riva/riva_hw.c b/drivers/video/fbdev/riva/riva_hw.c
index 8bdf37f..0601c13 100644
--- a/drivers/video/fbdev/riva/riva_hw.c
+++ b/drivers/video/fbdev/riva/riva_hw.c
@@ -1108,7 +1108,8 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
unsigned pixelDepth,
unsigned *burst,
unsigned *lwm,
- RIVA_HW_INST *chip
+ RIVA_HW_INST *chip,
+ struct pci_dev *pdev
)
{
nv10_fifo_info fifo_data;
@@ -1116,8 +1117,9 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
unsigned int M, N, P, pll, MClk, NVClk;
unsigned int uMClkPostDiv;
struct pci_dev *dev;
+ int domain = pci_domain_nr(pdev->bus);
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0x6C, &uMClkPostDiv);
pci_dev_put(dev);
uMClkPostDiv = (uMClkPostDiv >> 8) & 0xf;
@@ -1132,7 +1134,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &sim_data.memory_type);
pci_dev_put(dev);
sim_data.memory_type = (sim_data.memory_type >> 12) & 1;
@@ -1234,6 +1236,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
(
RIVA_HW_INST *chip,
RIVA_HW_STATE *state,
+ struct pci_dev *pdev,
int bpp,
int width,
int hDisplaySize,
@@ -1300,7 +1303,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
pixelDepth * 8,
&(state->arbitration0),
&(state->arbitration1),
- chip);
+ chip, pdev);
} else {
nv10UpdateArbitrationSettings(VClk,
pixelDepth * 8,
@@ -2102,10 +2105,12 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
static void nv10GetConfig
(
RIVA_HW_INST *chip,
+ struct pci_dev *pdev,
unsigned int chipset
)
{
struct pci_dev* dev;
+ int domain = pci_domain_nr(pdev->bus);
u32 amt;
#ifdef __BIG_ENDIAN
@@ -2118,12 +2123,12 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
* Fill in chip configuration.
*/
if(chipset == NV_CHIP_IGEFORCE2) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &amt);
pci_dev_put(dev);
chip->RamAmountKBytes = (((amt >> 6) & 31) + 1) * 1024;
} else if(chipset == NV_CHIP_0x01F0) {
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x84, &amt);
pci_dev_put(dev);
chip->RamAmountKBytes = (((amt >> 4) & 127) + 1) * 1024;
@@ -2224,6 +2229,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
int RivaGetConfig
(
RIVA_HW_INST *chip,
+ struct pci_dev *pdev,
unsigned int chipset
)
{
@@ -2245,7 +2251,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, nv3_sim_state * state, nv3_ar
case NV_ARCH_10:
case NV_ARCH_20:
case NV_ARCH_30:
- nv10GetConfig(chip, chipset);
+ nv10GetConfig(chip, pdev, chipset);
break;
default:
return (-1);
diff --git a/drivers/video/fbdev/riva/riva_hw.h b/drivers/video/fbdev/riva/riva_hw.h
index c2769f7..5e7b354 100644
--- a/drivers/video/fbdev/riva/riva_hw.h
+++ b/drivers/video/fbdev/riva/riva_hw.h
@@ -536,6 +536,7 @@
(
RIVA_HW_INST *chip,
RIVA_HW_STATE *state,
+ struct pci_dev *pdev,
int bpp,
int width,
int hDisplaySize,
@@ -546,7 +547,7 @@
/*
* External routines.
*/
-int RivaGetConfig(RIVA_HW_INST *, unsigned int);
+int RivaGetConfig(RIVA_HW_INST *chip, struct pci_dev *pdev, unsigned int c);
/*
* FIFO Free Count. Should attempt to yield processor if RIVA is busy.
*/
--
1.9.1
^ permalink raw reply related
* [PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev
member to extract the domain information and pass it to
pci_get_domain_bus_and_slot() function.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/nvidia/nv_hw.c | 11 ++++++-----
drivers/video/fbdev/nvidia/nv_setup.c | 3 ++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/nvidia/nv_hw.c b/drivers/video/fbdev/nvidia/nv_hw.c
index 81c80ac..8335da4 100644
--- a/drivers/video/fbdev/nvidia/nv_hw.c
+++ b/drivers/video/fbdev/nvidia/nv_hw.c
@@ -683,10 +683,11 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
nv10_sim_state sim_data;
unsigned int M, N, P, pll, MClk, NVClk, memctrl;
struct pci_dev *dev;
+ int domain = pci_domain_nr(par->pci_dev->bus);
if ((par->Chipset & 0x0FF0) == 0x01A0) {
unsigned int uMClkPostDiv;
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0x6C, &uMClkPostDiv);
uMClkPostDiv = (uMClkPostDiv >> 8) & 0xf;
@@ -694,7 +695,7 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
uMClkPostDiv = 4;
MClk = 400000 / uMClkPostDiv;
} else {
- dev = pci_get_bus_and_slot(0, 5);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 5);
pci_read_config_dword(dev, 0x4c, &MClk);
MClk /= 1000;
}
@@ -707,13 +708,13 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
sim_data.pix_bpp = (char)pixelDepth;
sim_data.enable_video = 0;
sim_data.enable_mp = 0;
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 1);
pci_read_config_dword(dev, 0x7C, &sim_data.memory_type);
pci_dev_put(dev);
sim_data.memory_type = (sim_data.memory_type >> 12) & 1;
sim_data.memory_width = 64;
- dev = pci_get_bus_and_slot(0, 3);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 3);
pci_read_config_dword(dev, 0, &memctrl);
pci_dev_put(dev);
memctrl >>= 16;
@@ -721,7 +722,7 @@ static void nForceUpdateArbitrationSettings(unsigned VClk,
if ((memctrl == 0x1A9) || (memctrl == 0x1AB) || (memctrl == 0x1ED)) {
u32 dimm[3];
- dev = pci_get_bus_and_slot(0, 2);
+ dev = pci_get_domain_bus_and_slot(domain, 0, 2);
pci_read_config_dword(dev, 0x40, &dimm[0]);
dimm[0] = (dimm[0] >> 8) & 0x4f;
pci_read_config_dword(dev, 0x44, &dimm[1]);
diff --git a/drivers/video/fbdev/nvidia/nv_setup.c b/drivers/video/fbdev/nvidia/nv_setup.c
index 2f2e162..b17acd2 100644
--- a/drivers/video/fbdev/nvidia/nv_setup.c
+++ b/drivers/video/fbdev/nvidia/nv_setup.c
@@ -264,7 +264,8 @@ static void nv10GetConfig(struct nvidia_par *par)
}
#endif
- dev = pci_get_bus_and_slot(0, 1);
+ dev = pci_get_domain_bus_and_slot(pci_domain_nr(par->pci_dev->bus),
+ 0, 1);
if ((par->Chipset & 0xffff) == 0x01a0) {
u32 amt;
--
1.9.1
^ permalink raw reply related
* [PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Find the domain number from pdev.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/intelfb/intelfbhw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/intelfb/intelfbhw.c b/drivers/video/fbdev/intelfb/intelfbhw.c
index 83fec57..57aff74 100644
--- a/drivers/video/fbdev/intelfb/intelfbhw.c
+++ b/drivers/video/fbdev/intelfb/intelfbhw.c
@@ -181,7 +181,9 @@ int intelfbhw_get_memory(struct pci_dev *pdev, int *aperture_size,
return 1;
/* Find the bridge device. It is always 0:0.0 */
- if (!(bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0)))) {
+ bridge_dev = pci_get_domain_bus_and_slot(pci_domain_nr(pdev->bus), 0,
+ PCI_DEVFN(0, 0));
+ if (!bridge_dev) {
ERR_MSG("cannot find bridge device\n");
return 1;
}
--
1.9.1
^ permalink raw reply related
* [PATCH V4 21/26] backlight: deprecate pci_get_bus_and_slot()
From: Sinan Kaya @ 2017-12-19 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513661883-28662-1-git-send-email-okaya@codeaurora.org>
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Hard-coding the domain as 0.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
---
drivers/video/backlight/apple_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/apple_bl.c b/drivers/video/backlight/apple_bl.c
index d843296..6a34ab9 100644
--- a/drivers/video/backlight/apple_bl.c
+++ b/drivers/video/backlight/apple_bl.c
@@ -143,7 +143,7 @@ static int apple_bl_add(struct acpi_device *dev)
struct pci_dev *host;
int intensity;
- host = pci_get_bus_and_slot(0, 0);
+ host = pci_get_domain_bus_and_slot(0, 0, 0);
if (!host) {
pr_err("unable to find PCI host\n");
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox