* [PATCH v2 3/6] arm: dts: sun8i: a83t: Add the cir pin for the A83T
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218141146.23746-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..feffca8a9a24 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -623,6 +623,11 @@
drive-strength = <20>;
bias-pull-up;
};
+
+ cir_pins: cir-pins at 0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.11.0
^ permalink raw reply related
* [PATCH v2 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218141146.23746-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..3d7f18780fae 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 Herz. 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 v2 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-18 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218141146.23746-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 v2 0/6] arm: sunxi: IR support for A83T
From: Philipp Rossak @ 2017-12-18 14:11 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 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
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Rafael J. Wysocki @ 2017-12-18 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513588684-15647-1-git-send-email-mw@semihalf.com>
On 12/18/2017 10:17 AM, Marcin Wojtas wrote:
> Hi,
>
> This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> First three patches introduce fwnode helpers for obtaining PHY
> information from nodes and also MDIO fwnode API for registering
> the bus with its PHY/devices.
>
> Following patches update code of the mvmdio and mvpp2 drivers
> to support ACPI tables handling. The latter is done in 4 steps,
> as can be seen in the commits. For the details, please
> refer to the commit messages.
>
> Drivers operation was tested on top of the net-next branch
> with both DT and ACPI. Although for compatibility reasons
> with older platforms, the mvmdio driver keeps using
> of_ MDIO registering, new fwnode_ one proved to fully work
> with DT as well (tested on MacchiatoBin board).
>
> mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> on a public branch:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> It was compiled together with the most recent Tianocore EDK2 revision.
> Please refer to the firmware build instruction on MacchiatoBin board:
> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>
> Above support configures 1G to use its PHY normally. 10G can work now
> only with the link interrupt mode. Somehow reading of the
> string property in fwnode_mdiobus_child_is_phy works only with
> DT and cannot cope with 10G PHY nodes as in:
> https://pastebin.com/3JnYpU0A
>
> Above root cause will be further checked. In the meantime I will
> appreciate any comments or remarks for the kernel patches.
>
> Best regards,
> Marcin
>
> Marcin Wojtas (8):
> device property: Introduce fwnode_get_mac_address()
> device property: Introduce fwnode_get_phy_mode()
> mdio_bus: Introduce fwnode MDIO helpers
> net: mvmdio: add ACPI support
> net: mvpp2: simplify maintaining enabled ports' list
> net: mvpp2: use device_*/fwnode_* APIs instead of of_*
> net: mvpp2: handle PHY with its fwnode
> net: mvpp2: enable ACPI support in the driver
>
> drivers/base/property.c | 52 +++--
> drivers/net/ethernet/marvell/mvmdio.c | 42 +++-
> drivers/net/ethernet/marvell/mvpp2.c | 246 ++++++++++++--------
> drivers/net/phy/mdio_bus.c | 218 +++++++++++++++++
> include/linux/mdio.h | 3 +
> include/linux/property.h | 3 +
> 6 files changed, 454 insertions(+), 110 deletions(-)
>
Please CC linux-acpi on all submissions of patches touching ACPI,
property.c or property.h.
Thanks!
^ permalink raw reply
* [PATCH net-next 2/2 v9] net: ethernet: Add a driver for Gemini gigabit ethernet
From: Linus Walleij @ 2017-12-18 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216193911.6938-2-linus.walleij@linaro.org>
On Sat, Dec 16, 2017 at 8:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> The Gemini ethernet has been around for years as an out-of-tree
> patch used with the NAS boxen and routers built on StorLink
> SL3512 and SL3516, later Storm Semiconductor, later Cortina
> Systems. These ASICs are still being deployed and brand new
> off-the-shelf systems using it can easily be acquired.
>
> The full name of the IP block is "Net Engine and Gigabit
> Ethernet MAC" commonly just called "GMAC".
>
> The hardware block contains a common TCP Offload Enginer (TOE)
> that can be used by both MACs. The current driver does not use
> it.
>
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Changes from v8:
> - Remove dependency guards in Kconfig to get a wider compile
> coverage for the driver to detect broken APIs etc.
I guess we need to hold this off for a while, the code does
some weird stuff using the ARM-internal page DMA mapping
API.
I *think* what happens is that the driver allocates a global queue
used for RX and TX on both interfaces, then initializes that with
page pointers and gives that to the hardware to play with.
When an RX packet comes in, the RX routine needs to figure
out from the DMA (physical) address which remapped
page/address this random physical address pointer
corresponds to.
The Linux DMA API assumption is that the driver keeps track
of this mapping, not the hardware. So we need to figure out
a way to reverse-map this. Preferably quickly, and without
using any ARM-internal mapping APIs.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: B15: fix unused label warnings
From: Arnd Bergmann @ 2017-12-18 13:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218134430.GD10595@n2100.armlinux.org.uk>
On Mon, Dec 18, 2017 at 2:44 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Mon, Dec 18, 2017 at 02:41:11PM +0100, Arnd Bergmann wrote:
>> The new conditionally compiled code leaves some labels and one
>> variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
>> are disabled:
>>
>> arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
>> arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
>> out_unmap:
>> ^~~~~~~~~
>> arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
>> out_cpu_dead:
>> ^~~~~~~~~~~~
>> At top level:
>> arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
>>
>> This adds more #ifdefs around them.
>>
>> Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> Florian, if this looks good to you, please forward the fix into Russell's
>> patch tracker, otherwise just send a better fix.
>
> I'd prefer a better fix than yet more ifdefs...
Ok, I've reworked my patch now to replace the existing #ifdef with if
(IS_ENABLED())
checks instead, which makes it look much nicer.
I'll send the new version after more randconfig testing.
Arnd
^ permalink raw reply
* [PATCH v3 04/11] thermal: armada: Rationalize register accesses
From: Miquel RAYNAL @ 2017-12-18 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085622.6u4dmvyaph3mbb66@tarshish>
On Fri, 15 Dec 2017 10:56:22 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Thu, Dec 14, 2017 at 11:30:04AM +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>
> > ---
> > drivers/thermal/armada_thermal.c | 86
> > +++++++++++++++++++++++++--------------- 1 file changed, 55
> > insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 26698f2d3ca7..e5b184cee79b
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -39,12 +39,21 @@
> > #define A375_HW_RESETn BIT(8)
> > #define A380_HW_RESET BIT(8)
> >
> > +/* Legacy bindings */
> > +#define LEGACY_CONTROL_MEM_LEN 0x4
> > +
> > +/* Current bindings with the 2 control registers under the same
> > memory area */ +#define LEGACY_CONTROL1_OFFSET 0x0
> > +#define CONTROL0_OFFSET 0x0
> > +#define CONTROL1_OFFSET 0x4
> > +
> > struct armada_thermal_data;
> >
> > /* Marvell EBU Thermal Sensor Dev Structure */
> > struct armada_thermal_priv {
> > - void __iomem *sensor;
> > - void __iomem *control;
> > + void __iomem *status;
> > + void __iomem *control0;
> > + void __iomem *control1;
>
> The 'status' -> 'sensor' rename is not mentioned in the commit log.
> I'd say it is a matter for a separate patch.
Sure, I'll split.
>
> Otherwise, good cleanup.
Thanks!
Miqu?l
>
> baruch
>
> > struct armada_thermal_data *data;
> > };
> >
> > @@ -71,45 +80,45 @@ struct armada_thermal_data {
> > static void armadaxp_init_sensor(struct platform_device *pdev,
> > struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg;
> > + u32 reg;
> >
> > - reg = readl_relaxed(priv->control);
> > + reg = readl_relaxed(priv->control1);
> > reg |= PMU_TDC0_OTF_CAL_MASK;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Reference calibration value */
> > reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> > reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Reset the sensor */
> > - reg = readl_relaxed(priv->control);
> > - writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> > + reg = readl_relaxed(priv->control1);
> > + writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
> >
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Enable the sensor */
> > - reg = readl_relaxed(priv->sensor);
> > + reg = readl_relaxed(priv->status);
> > reg &= ~PMU_TM_DISABLE_MASK;
> > - writel(reg, priv->sensor);
> > + writel(reg, priv->status);
> > }
> >
> > static void armada370_init_sensor(struct platform_device *pdev,
> > struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg;
> > + u32 reg;
> >
> > - reg = readl_relaxed(priv->control);
> > + reg = readl_relaxed(priv->control1);
> > reg |= PMU_TDC0_OTF_CAL_MASK;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > /* Reference calibration value */
> > reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> > reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > reg &= ~PMU_TDC0_START_CAL_MASK;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> >
> > msleep(10);
> > }
> > @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct
> > platform_device *pdev, static void armada375_init_sensor(struct
> > platform_device *pdev, struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg;
> > + u32 reg;
> >
> > - reg = readl(priv->control + 4);
> > + reg = readl(priv->control1);
> > reg &= ~(A375_UNIT_CONTROL_MASK <<
> > A375_UNIT_CONTROL_SHIFT); reg &= ~A375_READOUT_INVERT;
> > reg &= ~A375_HW_RESETn;
> >
> > - writel(reg, priv->control + 4);
> > + writel(reg, priv->control1);
> > msleep(20);
> >
> > reg |= A375_HW_RESETn;
> > - writel(reg, priv->control + 4);
> > + writel(reg, priv->control1);
> > msleep(50);
> > }
> >
> > static void armada380_init_sensor(struct platform_device *pdev,
> > struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg = readl_relaxed(priv->control);
> > + u32 reg = readl_relaxed(priv->control1);
> >
> > /* Reset hardware once */
> > if (!(reg & A380_HW_RESET)) {
> > reg |= A380_HW_RESET;
> > - writel(reg, priv->control);
> > + writel(reg, priv->control1);
> > msleep(10);
> > }
> > }
> >
> > static bool armada_is_valid(struct armada_thermal_priv *priv)
> > {
> > - unsigned long reg = readl_relaxed(priv->sensor);
> > + u32 reg = readl_relaxed(priv->status);
> >
> > return reg & priv->data->is_valid_bit;
> > }
> > @@ -156,7 +165,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> > {
> > struct armada_thermal_priv *priv = thermal->devdata;
> > - unsigned long reg;
> > + u32 reg;
> > unsigned long m, b, div;
> >
> > /* Valid check */
> > @@ -166,7 +175,7 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, return -EIO;
> > }
> >
> > - reg = readl_relaxed(priv->sensor);
> > + reg = readl_relaxed(priv->status);
> > reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask;
> > /* Get formula coeficients */
> > @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of,
> > armada_thermal_id_table);
> > static int armada_thermal_probe(struct platform_device *pdev)
> > {
> > + void __iomem *control = NULL;
> > struct thermal_zone_device *thermal;
> > const struct of_device_id *match;
> > struct armada_thermal_priv *priv;
> > @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct
> > platform_device *pdev) return -ENOMEM;
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> > - if (IS_ERR(priv->sensor))
> > - return PTR_ERR(priv->sensor);
> > + priv->status = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(priv->status))
> > + return PTR_ERR(priv->status);
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> > - priv->control = devm_ioremap_resource(&pdev->dev, res);
> > - if (IS_ERR(priv->control))
> > - return PTR_ERR(priv->control);
> > + control = devm_ioremap_resource(&pdev->dev, res);
> > + if (IS_ERR(control))
> > + return PTR_ERR(control);
> > +
> > + /*
> > + * 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 ((res->end - res->start) == 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;
> > + }
> >
> > priv->data = (struct armada_thermal_data *)match->data;
> > priv->data->init_sensor(pdev, priv);
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: B15: fix unused label warnings
From: Russell King - ARM Linux @ 2017-12-18 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218134126.2913861-1-arnd@arndb.de>
On Mon, Dec 18, 2017 at 02:41:11PM +0100, Arnd Bergmann wrote:
> The new conditionally compiled code leaves some labels and one
> variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
> are disabled:
>
> arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
> arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
> out_unmap:
> ^~~~~~~~~
> arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
> out_cpu_dead:
> ^~~~~~~~~~~~
> At top level:
> arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
>
> This adds more #ifdefs around them.
>
> Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Florian, if this looks good to you, please forward the fix into Russell's
> patch tracker, otherwise just send a better fix.
I'd prefer a better fix than yet more ifdefs...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] ARM: B15: fix unused label warnings
From: Arnd Bergmann @ 2017-12-18 13:41 UTC (permalink / raw)
To: linux-arm-kernel
The new conditionally compiled code leaves some labels and one
variable unreferenced when CONFIG_HOTPLUG_CPU and CONFIG_PM_SLEEP
are disabled:
arch/arm/mm/cache-b15-rac.c: In function 'b15_rac_init':
arch/arm/mm/cache-b15-rac.c:353:1: error: label 'out_unmap' defined but not used [-Werror=unused-label]
out_unmap:
^~~~~~~~~
arch/arm/mm/cache-b15-rac.c:351:1: error: label 'out_cpu_dead' defined but not used [-Werror=unused-label]
out_cpu_dead:
^~~~~~~~~~~~
At top level:
arch/arm/mm/cache-b15-rac.c:53:12: error: 'rac_config0_reg' defined but not used [-Werror=unused-variable]
This adds more #ifdefs around them.
Fixes: 55de88778f4b ("ARM: 8726/1: B15: Add CPU hotplug awareness")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Florian, if this looks good to you, please forward the fix into Russell's
patch tracker, otherwise just send a better fix.
---
arch/arm/mm/cache-b15-rac.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mm/cache-b15-rac.c b/arch/arm/mm/cache-b15-rac.c
index f76988790011..24cb3b7a0501 100644
--- a/arch/arm/mm/cache-b15-rac.c
+++ b/arch/arm/mm/cache-b15-rac.c
@@ -50,7 +50,10 @@ extern void v7_flush_kern_cache_all(void);
static void __iomem *b15_rac_base;
static DEFINE_SPINLOCK(rac_lock);
+
+#if IS_ENABLED(CONFIG_HOTPLUG_CPU) || IS_ENABLED(CONFIG_PM_SLEEP)
static u32 rac_config0_reg;
+#endif
/* Initialization flag to avoid checking for b15_rac_base, and to prevent
* multi-platform kernels from crashing here as well.
@@ -348,11 +351,13 @@ static int __init b15_rac_init(void)
goto out;
+#ifdef CONFIG_HOTPLUG_CPU
out_cpu_dead:
cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CACHE_B15_RAC_DYING);
out_unmap:
unregister_reboot_notifier(&b15_rac_reboot_nb);
iounmap(b15_rac_base);
+#endif
out:
of_node_put(dn);
return ret;
--
2.9.0
^ permalink raw reply related
* [PATCH v5 0/8] omap: dmtimer: Move driver out of plat-omap
From: Ladislav Michl @ 2017-12-18 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3b721525-c97d-925d-5904-83515abc4b38@ti.com>
On Mon, Dec 18, 2017 at 06:24:42PM +0530, Keerthy wrote:
> On Monday 18 December 2017 04:46 PM, Ladislav Michl wrote:
> > Keerthy,
> >
> > On Tue, Dec 12, 2017 at 11:42:09AM +0530, Keerthy wrote:
> >> The series moves dmtimer out of plat-omap to drivers/clocksource.
> >> The series also does a bunch of changes to pwm-omap-dmtimer code
> >> to adapt to the driver migration and clean up plat specific
> >> pdata-quirks and use the dmtimer platform data.
> >
> > thanks for nice work. I'll send two more patches as a reply to this
> > one. I'd be glad if you could make them part of your serie. One of
> > them would be nice to have for pwm driver prescaler fix which will
> > be send independently.
> > Also, if that helps you can have my
> > Tested-by: Ladislav Michl <ladis@linux-mips.org>
> > on IGEPv2 (OMAP3430 based)
>
> Thanks a bunch! :-). I will take the pwm driver fix along with mine.
>
> should i also take the two patches which you sent:
>
> [PATCH 1/2] clocksource: timer-dm: Make unexported functions static
> [PATCH 2/2] clocksource: timer-dm: Check prescaler value
It would be great, if you could add those above to your serie.
> Also what about this:
> [PATCH] pwm: omap-dmtimer: Fix frequency when using prescaler
This one is independent of your serie, just "[PATCH 2/2] clocksource:
timer-dm: Check prescaler value" makes it a bit more error prone,
but there is no compile nor runtime dependency.
Perhaps it could me merged directly via pwm tree after some review?
I have few more patches to add event capture support, based on top
of those already sent, which I'll send separately.
> Let me know. I plan to send v6 with your Tested-by.
>
> Thanks,
> Keerthy
Thank you,
ladis
^ permalink raw reply
* [PATCH v2 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Stefan Agner @ 2017-12-18 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uHFcHnh-CHLfJwgeB1M8niWBtdpVv-f+Dr7b43f70zwbw@mail.gmail.com>
On 2017-12-17 23:55, Philippe Ombredanne wrote:
> Fabio,
>
> On Sun, Dec 17, 2017 at 10:59 PM, Fabio Estevam <festevam@gmail.com> wrote:
>> Hi Stefan,
>>
>> On Sun, Dec 17, 2017 at 6:37 PM, Stefan Agner <stefan@agner.ch> wrote:
>>
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
>>> @@ -0,0 +1,20 @@
>>> +/*
>>> + * Copyright 2017 Toradex AG
>>> + *
>>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> + */
>>
>> In the previous patch you used GPL-2.0 text, instead of GPL-2.0+.
>>
>> The SPDX line should be the first one and start with a // style comment:
>>
>> // SPDX-License-Identifier: (GPL-2.0 OR MIT)
Hm, good catch, I copied the above from some uniphier device tree. Will
fix.
>
> Yes this line as the top line is the correct way as explained in
> Thomas doc patches [1]
> I cannot comment of whether the author wants GPL 2 or 2+ though KISS is best.
>
> [1] https://lkml.org/lkml/2017/12/4/934
>
Oh, I see now, you refer to that patch in particular:
https://lkml.org/lkml/2017/12/4/942
>> Philippe, please confirm this is the correct way.
>>
>> With this fixed you can add:
>>
>> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Thank!
--
Stefan
^ permalink raw reply
* [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Keerthy @ 2017-12-18 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218093153.GA22729@lenoch>
On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:
> Keerthy,
>
> On Tue, Dec 12, 2017 at 11:42:16AM +0530, Keerthy wrote:
>> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
>>
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>> ---
>>
>> Changes in v4:
>>
>> * Switched to dev_get_platdata.
>
> Where do you expect dev.platform_data to be set? PWM driver is failing
> with:
> omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
> omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>
> Which I fixed with patch bellow, to be able to test your patchset.
Thanks! I will make the below patch part of my series.
>
> Also I'm running a bit out of time, so I'll send few clean up
> patches and event capture code to get some feedback early.
>
> Regards,
> ladis
>
> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> index 39be39e6a8dd..d3d8a49cae0d 100644
> --- a/drivers/clocksource/timer-dm.c
> +++ b/drivers/clocksource/timer-dm.c
> @@ -773,6 +773,7 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
> dev_err(dev, "%s: no platform data.\n", __func__);
> return -ENODEV;
> }
> + dev->platform_data = pdata;
>
> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> if (unlikely(!irq)) {
>
>>
>> Changes in v3:
>>
>> * Used of_find_platdata_by_node function to fetch platform
>> data for timer node.
>>
>> drivers/pwm/pwm-omap-dmtimer.c | 39 ++++++++++++++++++++++-----------------
>> 1 file changed, 22 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH v5 0/8] omap: dmtimer: Move driver out of plat-omap
From: Keerthy @ 2017-12-18 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218111610.GA16906@lenoch>
On Monday 18 December 2017 04:46 PM, Ladislav Michl wrote:
> Keerthy,
>
> On Tue, Dec 12, 2017 at 11:42:09AM +0530, Keerthy wrote:
>> The series moves dmtimer out of plat-omap to drivers/clocksource.
>> The series also does a bunch of changes to pwm-omap-dmtimer code
>> to adapt to the driver migration and clean up plat specific
>> pdata-quirks and use the dmtimer platform data.
>
> thanks for nice work. I'll send two more patches as a reply to this
> one. I'd be glad if you could make them part of your serie. One of
> them would be nice to have for pwm driver prescaler fix which will
> be send independently.
> Also, if that helps you can have my
> Tested-by: Ladislav Michl <ladis@linux-mips.org>
> on IGEPv2 (OMAP3430 based)
Thanks a bunch! :-). I will take the pwm driver fix along with mine.
should i also take the two patches which you sent:
[PATCH 1/2] clocksource: timer-dm: Make unexported functions static
[PATCH 2/2] clocksource: timer-dm: Check prescaler value
Also what about this:
[PATCH] pwm: omap-dmtimer: Fix frequency when using prescaler
Let me know. I plan to send v6 with your Tested-by.
Thanks,
Keerthy
>
>> Boot tested on DRA7-EVM and AM437X-GP-EVM.
>
> I guess PWM driver was not tested, right? See comment to PATCH 7/8.
>
>> Compile tested omap1_defconfig.
Yes! Thanks for your feedback.
>
> Thank you,
> ladis
>
^ permalink raw reply
* [PATCH 1/5] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-18 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218024444.GA9140@gangnam.samsung>
Hey Andi,
thanks for the feedback. I will fix that in the next version of this
patch series!
On 18.12.2017 03:44, Andi Shyti wrote:
> Hi Philipp,
>
> just a couple of small nitpicks.
>
>> + u32 b_clk_freq;
>
> [...]
>
>> + /* Base clock frequency (optional) */
>> + if (of_property_read_u32(dn, "clock-frequency", &b_clk_freq)) {
>> + b_clk_freq = SUNXI_IR_BASE_CLK;
>> + }
>> +
>
> how about you intialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' and
> just call 'of_property_read_u32' without if statement.
> 'b_clk_freq' value should not be changed if "clock-frequency"
> is not present in the DTS.
>
> This might avoid misinterpretation from static analyzers that
> might think that 'b_clk_freq' is used uninitialized.
>
>> + dev_info(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
>
> Please use dev_dbg().
>
> Andi
>
--
Philipp
^ permalink raw reply
* [PATCH v5 7/9] arm64: Topology, rename cluster_id
From: Morten Rasmussen @ 2017-12-18 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7bb4e955-f3e5-d22f-4e78-eac97e66a9a6@arm.com>
On Fri, Dec 15, 2017 at 10:36:35AM -0600, Jeremy Linton wrote:
> Hi,
>
> On 12/13/2017 12:02 PM, Lorenzo Pieralisi wrote:
> >[+Morten, Dietmar]
> >
> >$SUBJECT should be:
> >
> >arm64: topology: rename cluster_id
>
> Sure..
>
> >
> >On Fri, Dec 01, 2017 at 04:23:28PM -0600, Jeremy Linton wrote:
> >>Lets match the name of the arm64 topology field
> >>to the kernel macro that uses it.
> >>
> >>Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> >>---
> >> arch/arm64/include/asm/topology.h | 4 ++--
> >> arch/arm64/kernel/topology.c | 27 ++++++++++++++-------------
> >> 2 files changed, 16 insertions(+), 15 deletions(-)
> >>
> >>diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> >>index c4f2d50491eb..118136268f66 100644
> >>--- a/arch/arm64/include/asm/topology.h
> >>+++ b/arch/arm64/include/asm/topology.h
> >>@@ -7,14 +7,14 @@
> >> struct cpu_topology {
> >> int thread_id;
> >> int core_id;
> >>- int cluster_id;
> >>+ int physical_id;
> >
> >package_id ?
>
> Given the macro is topology_physical_package_id, either makes sense to me.
> <shrug> I will change it in the next set.
I would vote for package_id too. arch/arm has 'socket_id' though.
> >
> >It has been debated before, I know. Should we keep the cluster_id too
> >(even if it would be 1:1 mapped to package_id - for now) ?
>
> Well given that this patch replaces the patch that did that at your
> request..
>
> I was hoping someone else would comment here, but my take at this point is
> that it doesn't really matter in a functional sense at the moment.
> Like the chiplet discussion it can be the subject of a future patch along
> with the patches which tweak the scheduler to understand the split.
>
> BTW, given that i'm OoO next week, and the following that are the holidays,
> I don't intend to repost this for a couple weeks. I don't think there are
> any issues with this set.
>
> >
> >There is also arch/arm to take into account, again, this patch is
> >just renaming (as it should have named since the beginning) a
> >topology level but we should consider everything from a legacy
> >perspective.
arch/arm has gone for thread/core/socket for the three topology levels
it supports.
I'm not sure what short term value keeping cluster_id has? Isn't it just
about where we make the package = cluster assignment? Currently it is in
the definition of topology_physical_package_id. If we keep cluster_id
and add package_id, it gets moved into the MPIDR/DT parsing code.
Keeping cluster_id and introducing a topology_cluster_id function could
help cleaning up some of the users of topology_physical_package_id that
currently assumes package_id == cluster_id though.
Morten
^ permalink raw reply
* [PATCH v3 04/11] thermal: armada: Rationalize register accesses
From: Miquel RAYNAL @ 2017-12-18 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217220235.4uwy4nw77gf3kvfp@tarshish>
On Mon, 18 Dec 2017 00:02:35 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Sun, Dec 17, 2017 at 12:18:38AM +0200, Baruch Siach wrote:
> > On Thu, Dec 14, 2017 at 11:30:04AM +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>
> > > ---
> >
> > [...]
> >
> > > + /*
> > > + * 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 ((res->end - res->start) == 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;
> > > + }
> >
> > I think we need to add a check here that the control registers area
> > size matches the expected value given the compatible string. In
> > case of mismatch probe should fail.
Ok I will check here for the bindings used.
Still, in the a380_init() I will have to check if control0 is
valid or not because this function should handle both bindings.
>
> One more thing. You should probably use resource_size() instead of
> open coding it. resource_size() does "res->end - res->start + 1". Are
> you sure your code is correct?
It is not regarding the implementation of resource_size() (which I'm
gonna use).
>
> > > priv->data = (struct armada_thermal_data *)match->data;
> > > priv->data->init_sensor(pdev, priv);
>
> baruch
>
Thank you,
Miqu?l
^ permalink raw reply
* [PATCH v2] ARM: dts: sun8i: h3: nanopi-m1-plus: fix missing ethernet 0 in aliases
From: Philipp Rossak @ 2017-12-18 12:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes a missing ethernet 0 alisas in the devicetree on the
Nanopi M1 Plus.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
index 0a8b79cf5954..87509a3e6aba 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts
@@ -48,6 +48,7 @@
aliases {
serial1 = &uart3;
+ ethernet0 = &emac;
ethernet1 = &sdio_wifi;
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 05/11] thermal: armada: Add support for Armada AP806
From: Miquel RAYNAL @ 2017-12-18 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218111156.76a66q5kwh3advs7@sapphire.tkos.co.il>
Hi Baruch,
On Mon, 18 Dec 2017 13:11:56 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Mon, Dec 18, 2017 at 10:41:27AM +0100, Miquel RAYNAL wrote:
> > Hello Gregory & Baruch,
> >
> > On Thu, 14 Dec 2017 12:05:43 +0100
> > Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> >
> > > > @@ -184,9 +214,9 @@ static int armada_get_temp(struct
> > > > thermal_zone_device *thermal, div = priv->data->coef_div;
> > > >
> > > > if (priv->data->inverted)
> > > > - *temp = ((m * reg) - b) / div;
> > > > + *temp = ((m * sample) - b) / div;
> > > > else
> > > > - *temp = (b - (m * reg)) / div;
> > > > + *temp = (b - (m * sample)) / div;
> > > > return 0;
> > > > }
> > > >
> > > > @@ -237,6 +267,19 @@ static const struct armada_thermal_data
> > > > armada380_data = { .inverted = true,
> > > > };
> > > >
> > > > +static const struct armada_thermal_data armada_ap806_data = {
> > > > + .is_valid = armada_is_valid,
> > > > + .init_sensor = armada_ap806_init_sensor,
> > > > + .is_valid_bit = BIT(16),
> > > > + .temp_shift = 0,
> > > > + .temp_mask = 0x3ff,
> > > > + .coef_b = -150000,
> > >
> > > Don't you expect any side effect by storing a negative value in a
> > > unsigned variable?
> >
> > That is a fair question, I did not spot that.
> >
> > As other values are really close to 2^32 I don't know what is the
> > best option for us in this case. Should I:
> > - don't care?
> > - use signed values? (dangerous IMHO)
> > - use a union with a signed and an unsigned value? (problem moved
> > to ->get_temp())
>
> Another option is to use s64 type.
I prefer this one!
Thank you,
Miqu?l
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 16/16] MAINTAINERS: add entry for Rockchip ISP1 driver
From: Jacob Chen @ 2017-12-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218121445.6086-1-jacob-chen@iotwrt.com>
From: Jacob Chen <jacob2.chen@rock-chips.com>
Add MAINTAINERS entry for the rockchip isp1 driver.
This driver is maintained by rockchip officially and it
will be used for rockchip SoC on all linux-kernel based OS.
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
MAINTAINERS | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b05bc2c5e85c..614196ed7265 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11665,6 +11665,16 @@ F: drivers/hid/hid-roccat*
F: include/linux/hid-roccat*
F: Documentation/ABI/*/sysfs-driver-hid-roccat*
+ROCKCHIP ISP V1 DRIVER
+M: Jacob chen <jacob2.chen@rock-chips.com>
+M: Shunqian Zheng <zhengsq@rock-chips.com>
+M: Yichong Zhong <zyc@rock-chips.com>
+L: linux-media at vger.kernel.org
+S: Maintained
+F: drivers/media/platform/rockchip/isp1/
+F: Documentation/devicetree/bindings/media/rockchip-isp1.txt
+F: Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
+
ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
M: Jacob chen <jacob2.chen@rock-chips.com>
L: linux-media at vger.kernel.org
--
2.15.1
^ permalink raw reply related
* [PATCH v4 15/16] arm64: dts: rockchip: add rx0 mipi-phy for rk3399
From: Jacob Chen @ 2017-12-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218121445.6086-1-jacob-chen@iotwrt.com>
From: Shunqian Zheng <zhengsq@rock-chips.com>
It's a Designware MIPI D-PHY, used for ISP0 in rk3399.
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 66a912fab5dd..8ef321f03010 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1292,6 +1292,16 @@
status = "disabled";
};
+ mipi_dphy_rx0: mipi-dphy-rx0 {
+ compatible = "rockchip,rk3399-mipi-dphy";
+ clocks = <&cru SCLK_MIPIDPHY_REF>,
+ <&cru SCLK_DPHY_RX0_CFG>,
+ <&cru PCLK_VIO_GRF>;
+ clock-names = "dphy-ref", "dphy-cfg", "grf";
+ power-domains = <&power RK3399_PD_VIO>;
+ status = "disabled";
+ };
+
u2phy0: usb2-phy at e450 {
compatible = "rockchip,rk3399-usb2phy";
reg = <0xe450 0x10>;
--
2.15.1
^ permalink raw reply related
* [PATCH v4 14/16] arm64: dts: rockchip: add isp0 node for rk3399
From: Jacob Chen @ 2017-12-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218121445.6086-1-jacob-chen@iotwrt.com>
From: Shunqian Zheng <zhengsq@rock-chips.com>
rk3399 have two ISP, but we havn't test isp1, so just add isp0 at present.
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index d340b58ab184..66a912fab5dd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1588,6 +1588,21 @@
status = "disabled";
};
+ isp0: isp0 at ff910000 {
+ compatible = "rockchip,rk3399-cif-isp";
+ reg = <0x0 0xff910000 0x0 0x4000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru SCLK_ISP0>,
+ <&cru ACLK_ISP0>, <&cru ACLK_ISP0_WRAPPER>,
+ <&cru HCLK_ISP0>, <&cru HCLK_ISP0_WRAPPER>;
+ clock-names = "clk_isp",
+ "aclk_isp", "aclk_isp_wrap",
+ "hclk_isp", "hclk_isp_wrap";
+ power-domains = <&power RK3399_PD_ISP0>;
+ iommus = <&isp0_mmu>;
+ status = "disabled";
+ };
+
isp0_mmu: iommu at ff914000 {
compatible = "rockchip,iommu";
reg = <0x0 0xff914000 0x0 0x100>, <0x0 0xff915000 0x0 0x100>;
--
2.15.1
^ permalink raw reply related
* [PATCH v4 13/16] ARM: dts: rockchip: add rx0 mipi-phy for rk3288
From: Jacob Chen @ 2017-12-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218121445.6086-1-jacob-chen@iotwrt.com>
From: Jacob Chen <jacob2.chen@rock-chips.com>
It's a Designware MIPI D-PHY, used by ISP in rk3288.
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
arch/arm/boot/dts/rk3288.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index ed0b17d1b116..aa9ad3a6e0a5 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -864,6 +864,13 @@
status = "disabled";
};
+ mipi_phy_rx0: mipi-phy-rx0 {
+ compatible = "rockchip,rk3288-mipi-dphy";
+ clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_CSI>;
+ clock-names = "dphy-ref", "pclk";
+ status = "disabled";
+ };
+
io_domains: io-domains {
compatible = "rockchip,rk3288-io-voltage-domain";
status = "disabled";
--
2.15.1
^ permalink raw reply related
* [PATCH v4 12/16] ARM: dts: rockchip: add isp node for rk3288
From: Jacob Chen @ 2017-12-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218121445.6086-1-jacob-chen@iotwrt.com>
From: Jacob Chen <jacob2.chen@rock-chips.com>
rk3288 have a Embedded 13M ISP
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
arch/arm/boot/dts/rk3288.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index f3e7f98c2724..ed0b17d1b116 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -962,6 +962,23 @@
status = "disabled";
};
+ isp: isp at ff910000 {
+ compatible = "rockchip,rk3288-cif-isp";
+ reg = <0x0 0xff910000 0x0 0x4000>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru SCLK_ISP>, <&cru ACLK_ISP>,
+ <&cru HCLK_ISP>, <&cru PCLK_ISP_IN>,
+ <&cru SCLK_ISP_JPE>;
+ clock-names = "clk_isp", "aclk_isp",
+ "hclk_isp", "pclk_isp_in",
+ "sclk_isp_jpe";
+ assigned-clocks = <&cru SCLK_ISP>, <&cru SCLK_ISP_JPE>;
+ assigned-clock-rates = <400000000>, <400000000>;
+ power-domains = <&power RK3288_PD_VIO>;
+ iommus = <&isp_mmu>;
+ status = "disabled";
+ };
+
isp_mmu: iommu at ff914000 {
compatible = "rockchip,iommu";
reg = <0x0 0xff914000 0x0 0x100>, <0x0 0xff915000 0x0 0x100>;
--
2.15.1
^ permalink raw reply related
* [PATCH v4 11/16] dt-bindings: Document the Rockchip MIPI RX D-PHY bindings
From: Jacob Chen @ 2017-12-18 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218121445.6086-1-jacob-chen@iotwrt.com>
From: Jacob Chen <jacob2.chen@rock-chips.com>
Add DT bindings documentation for Rockchip MIPI D-PHY RX
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
---
.../bindings/media/rockchip-mipi-dphy.txt | 88 ++++++++++++++++++++++
1 file changed, 88 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
diff --git a/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
new file mode 100644
index 000000000000..0571d7f35867
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-mipi-dphy.txt
@@ -0,0 +1,88 @@
+Rockchip SoC MIPI RX D-PHY
+-------------------------------------------------------------
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3288-mipi-dphy"
+ "rockchip,rk3399-mipi-dphy"
+- clocks : list of clock specifiers, corresponding to entries in
+ clock-names property;
+- clock-names: required clock name.
+
+MIPI RX0 D-PHY use registers in "general register files", it
+should be a child of the GRF.
+MIPI TXRX D-PHY have its own registers, it must have a reg property.
+
+Optional properties:
+- reg: offset and length of the register set for the device.
+
+port node
+-------------------
+
+The device node should contain two 'port' child nodes, according to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+The first port show the sensors connected in this mipi-dphy.
+- endpoint:
+ - remote-endpoint: Linked to a sensor with a MIPI CSI-2 video bus.
+ - data-lanes : (required) an array specifying active physical MIPI-CSI2
+ data input lanes and their mapping to logical lanes; the
+ D-PHY can't reroute lanes, so the array's content should
+ be consecutive and only its length is meaningful.
+
+The port node must contain at least one endpoint. It could have multiple endpoints
+linked to different sensors, but please note that they are not supposed to be
+actived at the same time.
+
+The second port should be connected to isp node.
+- endpoint:
+ - remote-endpoint: Linked to Rockchip ISP1, which is defined
+ in rockchip-isp1.txt.
+
+Device node example
+-------------------
+
+grf: syscon at ff770000 {
+ compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd";
+
+...
+
+ mipi_dphy_rx0: mipi-dphy-rx0 {
+ compatible = "rockchip,rk3399-mipi-dphy";
+ clocks = <&cru SCLK_MIPIDPHY_REF>,
+ <&cru SCLK_DPHY_RX0_CFG>,
+ <&cru PCLK_VIO_GRF>;
+ clock-names = "dphy-ref", "dphy-cfg", "grf";
+ power-domains = <&power RK3399_PD_VIO>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_in_wcam: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&wcam_out>;
+ data-lanes = <1 2>;
+ };
+ mipi_in_ucam: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&ucam_out>;
+ data-lanes = <1>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ dphy_rx0_out: endpoint {
+ remote-endpoint = <&isp0_mipi_in>;
+ };
+ };
+ };
+ };
+};
--
2.15.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