* [PATCH v3 2/4] net: phy: dp83867: add support for MAC impedance configuration
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -33,6 +33,7 @@
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
#define DP83867_RGMIIDCTL 0x0086
+#define DP83867_IO_MUX_CFG 0x0170
#define DP83867_SW_RESET BIT(15)
#define DP83867_SW_RESTART BIT(14)
@@ -62,10 +63,17 @@
/* RGMIIDCTL bits */
#define DP83867_RGMII_TX_CLK_DELAY_SHIFT 4
+/* IO_MUX_CFG bits */
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
+
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX 0x0
+#define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN 0x1f
+
struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
+ int io_impedance;
};
static int dp83867_ack_interrupt(struct phy_device *phydev)
@@ -111,6 +119,14 @@ static int dp83867_of_init(struct phy_device *phydev)
if (!of_node)
return -ENODEV;
+ dp83867->io_impedance = -EINVAL;
+
+ /* Optional configuration */
+ if (of_property_read_bool(of_node, "ti,max-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX;
+ else if (of_property_read_bool(of_node, "ti,min-output-impedance"))
+ dp83867->io_impedance = DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN;
+
ret = of_property_read_u32(of_node, "ti,rx-internal-delay",
&dp83867->rx_id_delay);
if (ret)
@@ -184,6 +200,18 @@ static int dp83867_config_init(struct phy_device *phydev)
phy_write_mmd_indirect(phydev, DP83867_RGMIIDCTL,
DP83867_DEVADDR, delay);
+
+ if (dp83867->io_impedance >= 0) {
+ val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR);
+
+ val &= ~DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+ val |= dp83867->io_impedance &
+ DP83867_IO_MUX_CFG_IO_IMPEDANCE_CTRL;
+
+ phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+ DP83867_DEVADDR, val);
+ }
}
return 0;
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 3/4] ARM: dts: dra72-evm-revc: add phy impedance settings
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..aafb594 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v3 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-06 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006051355.15947-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index aafb594..01e1f39 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy at 2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-impedance;
};
dp83867_1: ethernet-phy at 3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Venkatesh Vivekanandan @ 2016-10-06 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e1e514b-fc3b-ca96-4631-88d537019e08@arm.com>
On Wed, Oct 5, 2016 at 4:12 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On 05/10/16 06:27, Venkatesh Vivekanandan wrote:
>
> [...]
>
>
>>
>> Hang is seen while trying to dump trace _after_ disabling the ETM
>> source. Is it not supposed to work?.
>> It works fine, when dumped before disabling ETM source. Please find
>> the log below.
>>
>> linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
>> [ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
>> [ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> enabled
>> [ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 enabled
>> [ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 108.105492] coresight-tmc 20010000.etf: TMC read start
>> [ 108.404335] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 125.069740] coresight-tmc 20010000.etf: TMC read start
>> [ 125.184370] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
>> [ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
>> [ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 disabled
>> [ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> disabled
>> [ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> <---- It hangs here...
>>
>
> I get dd: failed to open '/dev/20010000.etf': Invalid argument
> once all the data is read.
>
It hangs in my board.
>> My firmware version,
>>
>> NOTICE: Booting Trusted Firmware
>> NOTICE: BL1: v1.1(debug):4a1dcde
>> NOTICE: BL1: Built : 17:54:40, Nov 24 2015
>> NOTICE: BL1: Booting BL2
>> NOTICE: BL2: v1.1(debug):4a1dcde
>> NOTICE: BL2: Built : 17:54:40, Nov 24 2015
>> NOTICE: BL1: Booting BL3-1
>> NOTICE: BL3-1: v1.1(debug):4a1dcde
>> NOTICE: BL3-1: Built : 17:54:40, Nov 24 2015
>> UEFI firmware (version 9ed6f7e built at 17:54:28 on Nov 24 2015)
>>
>
> OK, this looks as good as what Suzuki has, so should be fine.
> But it doesn't list SCP version, can you see that from the Linux boot
> logs ?(something like below)
>
> "scpi_protocol scpi: SCP Protocol 1.2 Firmware 1.17.0 version"
[ 2.537096] scpi_protocol scpi: SCP Protocol 1.0 Firmware 1.11.0 version
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* Coresight ETF trace dump failed in Juno r1 with 4.8-rc8
From: Venkatesh Vivekanandan @ 2016-10-06 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81bf19a4-5716-1a68-77c2-a0a98f19ecc0@arm.com>
On Wed, Oct 5, 2016 at 10:47 PM, Suzuki K Poulose
<Suzuki.Poulose@arm.com> wrote:
> On 05/10/16 06:27, Venkatesh Vivekanandan wrote:
>>
>> On Tue, Oct 4, 2016 at 7:59 PM, Suzuki K Poulose <Suzuki.Poulose@arm.com>
>> wrote:
>>>
>>> On 04/10/16 06:37, Venkatesh Vivekanandan wrote:
>>>>
>>>>
>>>> On Mon, Oct 3, 2016 at 6:44 PM, Sudeep Holla <sudeep.holla@arm.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi Venkatesh,
>>>>>
>>>>> On 03/10/16 12:36, Venkatesh Vivekanandan wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I am trying to collect ETF trace from Juno R1 and could see "cpu
>>>>>> stall" while dumping the trace. Attached is the log of sequence
>>>>>> followed. Was trying to collect the trace data from hardware and see
>>>>>> if it is any valid data. Am I missing anything here?.
>>>>>>
>>>>>
>>>>> There are few fixes from me and Suzuki queued for v4.9.
>>>>> Can you check if this issue persists even on linux-next ?
>>>>
>>>>
>>>>
>>>> Issue is the same in linux-next as well. Please find the attached log.
>>>>
>>>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>>>> [ 120.009698] INFO: rcu_preempt detected stalls on CPUs/tasks:
>>>> [ 120.015307] 2-...: (1 GPs behind) idle=f11/140000000000000/0
>>>> softirq=224/224 fqs=1903
>>>> [ 120.023226] (detected by 1, t=5255 jiffies, g=-1, c=-2, q=19)
>>>> [ 120.029001] Task dump for CPU 2:
>>>> [ 120.032190] dd R running task 0 1270 1267
>>>> 0x00000002
>>>> [ 120.039172] Call trace:
>>>> [ 120.041594] [<ffff000008085534>] __switch_to+0xc8/0xd4
>>>> [ 120.046675] [<0000000000020000>] 0x20000
>>>>
>>>> Steps followed,
>>>> # git clone
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>>>> linux-next
>>>> # cd linux-next
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig <---
>>>> enable coresight
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 Image
>>>> # make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs
>>>> # arch/arm64/boot/Image <--- copied this kernel
>>>> # arch/arm64/boot/dts/arm/juno-r1.dtb <--- copied this dtb
>>>>
>>>> Top commit in linux-next is,
>>>>
>>>> commit c7d3b912180a9bb0733e5cfab84e5a7493dd3599
>>>> Author: Stephen Rothwell <sfr@canb.auug.org.au>
>>>> Date: Tue Oct 4 14:52:03 2016 +1100
>>>>
>>>> Add linux-next specific files for 20161004
>>>
>>>
>>>
>>> Can't reproduce it here either.
>>>
>>> root at localhost:/sys/bus/coresight/devices# echo 1 >
>>> 20010000.etf/enable_sink
>>> root at localhost:/sys/bus/coresight/devices# echo 1 >
>>> 22140000.etm/enable_source
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.227546 s, 288 kB/s
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.233527 s, 281 kB/s
>>> root at localhost:/sys/bus/coresight/devices# echo 0 >
>>> 20010000.etf/enable_sink
>>> root at localhost:/sys/bus/coresight/devices# dd if=/dev/20010000.etf bs=1
>>> of=/root/etr.bin
>>> 65536+0 records in
>>> 65536+0 records out
>>> 65536 bytes (66 kB) copied, 0.474943 s, 138 kB/s
>>>
>>> FWIW, here is my firmware version :
>>>
>>> NOTICE: Booting Trusted Firmware
>>> NOTICE: BL1: v1.1(release):e04723e21362
>>> NOTICE: BL1: Built : 15:39:56, Sep 1 2015
>>> NOTICE: BL1: Booting BL2
>>> NOTICE: BL2: v1.1(release):e04723e21362
>>> NOTICE: BL2: Built : 15:42:30, Sep 1 2015
>>> NOTICE: BL1: Booting BL3-1
>>> NOTICE: BL3-1: v1.1(release):604d5da6f2aa
>>> NOTICE: BL3-1: Built : 14:50:36, Sep 10 2015
>>> UEFI firmware (version ea31f8e built at 16:35:17 on Aug 5 2015)
>>>
>>
>> Hang is seen while trying to dump trace _after_ disabling the ETM
>> source. Is it not supposed to work?.
>> It works fine, when dumped before disabling ETM source. Please find
>> the log below.
>>
>> linaro-test [rc=0]# echo 1 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# echo 1 > 22140000.etm/enable_source
>> [ 91.792145] coresight-tmc 20010000.etf: TMC-ETB/ETF enabled
>> [ 91.797719] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> enabled
>> [ 91.804552] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 enabled
>> [ 91.815990] coresight-etm4x 22140000.etm: ETM tracing enabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 108.105492] coresight-tmc 20010000.etf: TMC read start
>> [ 108.404335] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> [ 125.069740] coresight-tmc 20010000.etf: TMC read start
>> [ 125.184370] coresight-tmc 20010000.etf: TMC read end
>> 65536+0 records in
>> 65536+0 records out
>> linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
>> [ 140.271163] coresight-etm4x 22140000.etm: ETM tracing disabled
>> [ 140.276964] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
>> inport 1 disabled
>> [ 140.284211] coresight-funnel 20040000.main-funnel: FUNNEL inport 0
>> disabled
>> [ 140.291128] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
>> linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
>> <---- It hangs here...
>
>
> The point is once you disable the source, which eventually disables
> all the components upto the sink, the data in the ETF is already captured
> into a buffer, so there is no coresight hardware access involved.
>
> Also, looks like the open(/dev/20010000.etf,..) from the dd didn't
> complete,
> as we don't see a "TMC read start" line.
>
> Could you please :
>
> a) Try the patch [0] and see if it helps ?
> b) If a doesn't help, after disabling the source, run any other command
> instead of the trace collection. e.g,
>
> dd if=/dev/zero of=/dev/null
>
> and see if it hangs the system in a similar way ?
Applied the patch(fixed unused variable warning) and tested. System
hangs the same way as before
with one extra print. dd to /dev/null works fine. Please find the log below.
linaro-test [rc=0]# echo 0 > 20010000.etf/enable_sink
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 60.519034] coresight-tmc 20010000.etf: TMC read start
[ 60.635825] coresight-tmc 20010000.etf: TMC read end
65536+0 records in
65536+0 records out
linaro-test [rc=0]# echo 0 > 22140000.etm/enable_source
[ 78.394169] coresight-etm4x 22140000.etm: ETM tracing disabled
[ 78.399977] coresight-funnel 220c0000.cluster0-funnel: FUNNEL
inport 1 disabled
[ 78.407225] coresight-funnel 20040000.main-funnel: FUNNEL inport 0 disabled
[ 78.414140] coresight-tmc 20010000.etf: TMC-ETB/ETF disabled
linaro-test [rc=0]# dd if=/dev/zero of=/dev/null bs=1 count=100
100+0 records in
100+0 records out
linaro-test [rc=0]# dd if=/dev/20010000.etf of=/cstrace.bin bs=1
[ 104.673413] coresight-tmc 20010000.etf: TMC read start
==== it just hangs here====
>
>
> Thanks
> Suzuki
>
> [0] test patch
>
> ----8>----
>
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index 1ffdab8..ef72ed8 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -511,13 +511,6 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> goto out;
> }
> - /* There is no point in reading a TMC in HW FIFO mode */
> - mode = readl_relaxed(drvdata->base + TMC_MODE);
> - if (mode != TMC_MODE_CIRCULAR_BUFFER) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> /* Don't interfere if operated from Perf */
> if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
>
>
>
^ permalink raw reply
* [PATCH v2 0/6] Support PWM polarity control
From: Lukasz Majewski @ 2016-10-06 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be9c9f6b22788ca4d9c9243a46932945@agner.ch>
Hi Stefan,
> Hi Lukasz,
>
> On 2016-10-04 00:48, Lukasz Majewski wrote:
> > Dear Bhuvanchandra,
> >
> > Thank you for your effort to send those patches to ML.
> >
> >> Changes since v2:
> >>
> >> - Picked the stalled patchset[1] from Lothar Wassmann which adds
> >> the basic support for polarity control on imx-pwm driver and adds
> >> backward compatibility support for devices which does not have
> >> polarity control feature.
> >>
> >> Changes since Lothars v6:
> >>
> >> - Squash Lukasz patch[2].
> >>
> >> [1] http://thread.gmane.org/gmane.linux.pwm/1621
> >> [2] https://www.spinics.net/lists/arm-kernel/msg530818.html
> >>
> >> Bhuvanchandra DV (3):
> >> arm: dts: imx7: Update #pwm-cells for PWM polarity control
> >> arm: dts: imx7-colibri: Use pwm polarity control
> >> arm: dts: imx7-colibri: Use enable-gpios for BL_ON
> >>
> >> Lothar Wassmann (3):
> >> pwm: print error messages with pr_err() instead of pr_debug()
> >> pwm: core: make the PWM_POLARITY flag in DTB optional
> >> pwm: imx: support output polarity inversion
> >
> > For some reason this patchset works differently than the one
> > developed by Lothar.
> >
> > The difference is with the brightness level control.
> >
> > My brightness definition in DTS:
> >
> > pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
> >
> > brightness-levels = < 0 1 2 3 4 5 6
> > 7 8 9
> >
> > .. ............
> > 250 251 252 253 254 255>;
> > default-brightness-level = <50>;
> > enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
> >
>
> If you are using something else than i.MX 7 you also want to update
> the SoC level device tree, specifically change the pwm-cells property:
> #pwm-cells = <3>;
Good point. However, it is declared elsewhere (with pwm2 node)
&pwm2 {
#pwm-cells = <3>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm2>;
status = "okay";
};
>
>
> > When I go to the backlight sysfs entry:
> >
> > cd /sys/devices/soc0/backlight/backlight/backlight
> >
> > It seems like the brightness level control is inverted - i.e.
> > 'echo 20 > brightness" makes picture on the screen very bright, and
> > 'echo 200 > brightness' makes the picture diminish.
> >
> > With my "internal" patches the situation is opposite (and I've
> > checked it with my HW connections).
>
> Just to check whether the driver actually applies the polarity you can
> add a #define DEBUG at the top of the driver (drivers/pwm/pwm-imx.c)
> and pass ignore_loglevel as kernel command line. This should give you
> "PWM supports output inversion" at startup and a "... polarity set
> to .." message whenever the polarity is set.
The problem is with the Bhuvanchandra original patch.
I will point it out when replying to original patch.
Thanks for support,
?ukasz Majewski
>
> --
> Stefan
>
> >
> > Could you check on your setup if similar situation takes place? I
> > mean if the brightness control works as expected?
> >
> > Thanks in advance,
> > ?ukasz Majewski
> >
> >>
> >> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +--
> >> arch/arm/boot/dts/imx7-colibri.dtsi | 12 +++++-
> >> arch/arm/boot/dts/imx7s.dtsi | 8 ++--
> >> drivers/pwm/core.c | 31
> >> ++++++++------ drivers/pwm/pwm-imx.c |
> >> 51 +++++++++++++++++++++-- 5 files changed, 83 insertions(+), 25
> >> deletions(-)
> >>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/67f38538/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 2/6] pwm: core: make the PWM_POLARITY flag in DTB optional
From: Lukasz Majewski @ 2016-10-06 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-3-bhuvanchandra.dv@toradex.com>
Hi Bhuvanchandra,
> From: Lothar Wassmann <LW@KARO-electronics.de>
>
> Change the pwm chip driver registration, so that a chip driver that
> supports polarity inversion can still be used with DTBs that don't
> provide the 'PWM_POLARITY' flag.
>
> This is done to provide polarity inversion support for the pwm-imx
> driver without having to modify all existing DTS files.
>
> Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> Suggested-by: Thierry Reding <thierry.reding@gmail.com>
> ---
> drivers/pwm/core.c | 27 ++++++++++++++++-----------
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 195373e..aae8db3 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -137,9 +137,14 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
> const struct of_phandle_args *args) {
> struct pwm_device *pwm;
>
> + /* check, whether the driver supports a third cell for flags
> */ if (pc->of_pwm_n_cells < 3)
> return ERR_PTR(-EINVAL);
>
> + /* flags in the third cell are optional */
> + if (args->args_count < 2)
> + return ERR_PTR(-EINVAL);
> +
> if (args->args[0] >= pc->npwm)
> return ERR_PTR(-EINVAL);
>
> @@ -149,10 +154,12 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc,
> const struct of_phandle_args *args)
> pwm->args.period = args->args[1];
>
> - if (args->args[2] & PWM_POLARITY_INVERTED)
> - pwm->args.polarity = PWM_POLARITY_INVERSED;
> - else
> - pwm->args.polarity = PWM_POLARITY_NORMAL;
> + if (args->args_count > 2) {
> + if (args->args[2] & PWM_POLARITY_INVERTED)
> + pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
^^^^^^^^^^^^^^^^
here we should set pwm->args.polarity, since
the pwm_set_polarity() calls pwm_apply_state()
which requires duty_cycle and period to be set.
In this particular moment it is not yet set and
polarity is not properly configured.
Patch fixing this will be sent as a reply to this e-mail. Please just
squash it and test on your platform.
Best regards,
?ukasz Majewski
> + else
> + pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
> + }
>
> return pwm;
> }
> @@ -163,9 +170,14 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const
> struct of_phandle_args *args) {
> struct pwm_device *pwm;
>
> + /* sanity check driver support */
> if (pc->of_pwm_n_cells < 2)
> return ERR_PTR(-EINVAL);
>
> + /* all cells are required */
> + if (args->args_count != pc->of_pwm_n_cells)
> + return ERR_PTR(-EINVAL);
> +
> if (args->args[0] >= pc->npwm)
> return ERR_PTR(-EINVAL);
>
> @@ -672,13 +684,6 @@ struct pwm_device *of_pwm_get(struct device_node
> *np, const char *con_id) goto put;
> }
>
> - if (args.args_count != pc->of_pwm_n_cells) {
> - pr_debug("%s: wrong #pwm-cells for %s\n",
> np->full_name,
> - args.np->full_name);
> - pwm = ERR_PTR(-EINVAL);
> - goto put;
> - }
> -
> pwm = pc->of_xlate(pc, &args);
> if (IS_ERR(pwm))
> goto put;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/743020b3/attachment.sig>
^ permalink raw reply
* [PATCH v2 5/6] arm: dts: imx7-colibri: Use pwm polarity control
From: Lukasz Majewski @ 2016-10-06 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-6-bhuvanchandra.dv@toradex.com>
On Sat, 1 Oct 2016 15:42:34 +0530
Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> wrote:
> Configure PWM polarity control.
>
> Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
> ---
> arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi
> b/arch/arm/boot/dts/imx7-colibri.dtsi index a9cc657..2af5e3e 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -43,7 +43,7 @@
> / {
> bl: backlight {
> compatible = "pwm-backlight";
> - pwms = <&pwm1 0 5000000>;
> + pwms = <&pwm1 0 5000000 0>;
My recommendation would be to add:
#include <dt-bindings/pwm/pwm.h>
and then define pwms as:
pwms = <&pwm1 0 5000000 PWM_POLARITY_NORMAL>;
It would be more readable
Best regards,
?ukasz Majewski
> };
>
> reg_module_3v3: regulator-module-3v3 {
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/124c447f/attachment.sig>
^ permalink raw reply
* [PATCH] pwm: core: Use pwm->args.polarity to setup PWM_POLARITY_INVERSED
From: Lukasz Majewski @ 2016-10-06 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161001101235.24598-3-bhuvanchandra.dv@toradex.com>
The pwm_set_polarity() function finally calls pwm_apply_state(), which
in turn requires state->duty_cycle and state->period properly set.
In the moment when polarity is set, the PWM is disabled and not configured.
For that reason both above variables are set to 0 and the polarity is not
set.
To be sure that polarity is setup, one needs to set pwm->args.polarity, which
controls MX3_PWMCR_POUTC bit setting at imx_pwm_config_v2().
Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
---
This patch should be applied on top of:
"[v2,2/6] pwm: core: make the PWM_POLARITY flag in DTB optional"
http://patchwork.ozlabs.org/patch/677330/
---
drivers/pwm/core.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1f62668..6cd6004 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -153,13 +153,11 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
return pwm;
pwm->args.period = args->args[1];
+ pwm->args.polarity = PWM_POLARITY_NORMAL;
- if (args->args_count > 2) {
+ if (args->args_count > 2)
if (args->args[2] & PWM_POLARITY_INVERTED)
- pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
- else
- pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
- }
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
return pwm;
}
--
2.1.4
^ permalink raw reply related
* linux-next: manual merge of the gpio tree with the arm-soc tree
From: Linus Walleij @ 2016-10-06 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006094114.764d2f34@canb.auug.org.au>
On Thu, Oct 6, 2016 at 12:41 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Tue, 27 Sep 2016 15:05:42 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the gpio tree got a conflict in:
>>
>> arch/arm/mach-omap2/board-rx51-peripherals.c
>>
>> between commit:
>>
>> 9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900")
>>
>> from the arm-soc tree and commit:
>>
>> 9132ce450bd1 ("ARM: omap2: fix missing include")
>>
>> from the gpio tree.
>>
>> I fixed it up (the former removed the file, so I did that) and can
>> carry the fix as necessary. This is now fixed as far as linux-next is
>> concerned, but any non trivial conflicts should be mentioned to your
>> upstream maintainer when your tree is submitted for merging. You may
>> also want to consider cooperating with the maintainer of the conflicting
>> tree to minimise any particularly complex conflicts.
>
> Since Linus (Torvalds) has merged the gpio tree, this conflict (and
> file removal) now affects the merge of the arm-soc tree).
Yup and I also informed him in my pull request about this conflict
so shouldn't be a problem.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-10-06 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8795dc49-26f9-0505-f442-2ca74b51872f@codeaurora.org>
Hi Archit,
On Mon, Oct 03, 2016 at 04:40:57PM +0530, Archit Taneja wrote:
> Hi Maxime,
>
> On 09/30/2016 08:07 PM, Maxime Ripard wrote:
> >Some boards have an entirely passive RGB to VGA bridge, based on either
> >DACs or resistor ladders.
> >
> >Those might or might not have an i2c bus routed to the VGA connector in
> >order to access the screen EDIDs.
> >
> >Add a bridge that doesn't do anything but expose the modes available on the
> >screen, either based on the EDIDs if available, or based on the XGA
> >standards.
> >
> >Acked-by: Rob Herring <robh@kernel.org>
> >Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >---
> > .../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
> > drivers/gpu/drm/bridge/Kconfig | 7 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++++++++++
> > 4 files changed, 285 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> > create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
> >
> >diff --git a/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> >new file mode 100644
> >index 000000000000..a8375bc1f9cb
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
> >@@ -0,0 +1,48 @@
> >+Dumb RGB to VGA bridge
> >+----------------------
> >+
> >+This binding is aimed for dumb RGB to VGA bridges that do not require
> >+any configuration.
> >+
> >+Required properties:
> >+
> >+- compatible: Must be "rgb-to-vga-bridge"
>
> I'd talked to Laurent on IRC if he's okay with this. And I guess you to
> had discussed it during XDC too. He's suggested that it'd be better to
> have the compatible string as "simple-vga-dac".
I just wished this bikeshedding had taken place publicly and be
actually part of that discussion, but yeah, ok.
> Some of the reasons behind having this:
>
> - We don't need to specify "rgb" in the compatible string since most
> simple VGA DACs can only work with an RGB input.
Ok.
> - Also, with "dac" specified in the string, we don't need to
> specifically mention "bridge" in the string. Also, bridge is a drm
> specific term.
>
> - "simple" is considered because it's an unconfigurable bridge, and it
> might be misleading for other VGA DACs to not use "vga-dac".
All those "simple" bindings are just the biggest lie we ever
told. It's simple when you introduce it, and then grows into something
much more complicated than a non-simple implementation.
> What do you think about this? If you think it's good, would it be
> possible for you to change this? I guess it's okay for the rest of
> the patch to stay the same.
I'll update and respin the serie.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161006/701c158a/attachment.sig>
^ permalink raw reply
* [PATCH v6 0/5] drm: Add Support for Passive RGB to VGA bridges
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This serie is about adding support for the RGB to VGA bridge found in
the A13-Olinuxino and the CHIP VGA adapter.
Both these boards rely on an entirely passive bridge made out of
resitor ladders that do not require any initialisation. The only thing
needed is to get the timings from the screen if available (and if not,
fall back on XGA standards), set up the display pipeline to output on
the RGB bus with the proper timings, and you're done.
This serie also fixes a bunch of bugs uncovered when trying to
increase the resolution, and hence the pixel clock, of our
pipeline. It also fixes a few bugs in the DRM driver itself that went
unnoticed before.
Let me know what you think,
Maxime
Changes from v5:
- Renamed to simple-vga-dac
Changes from v4:
- Removed unused functions
Changes from v3:
- Depends on OF in Kconfig
- Fixed typos in the driver comments
- Removed the mention of a "passive" bridge in the bindings doc
- Made the strcuture const
- Removed the nops and best_encoders implementations
- Removed the call to drm_bridge_enable in the sun4i driver
Changes from v2:
- Changed the compatible as suggested
- Rebased on top 4.8
Changes from v1:
- Switch to using a vga-connector
- Use drm_encoder bridge pointer instead of doing our own
- Report the connector status as unknown instead of connected by
default, and as connected only if we can retrieve the EDID.
- Switch to of_i2c_get_adapter by node, and put the reference when done
- Rebased on linux-next
Maxime Ripard (5):
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/bridge: Add RGB to VGA bridge support
ARM: sun5i: a13-olinuxino: Enable VGA bridge
ARM: multi_v7: enable VGA bridge
ARM: sunxi: Enable VGA bridge
.../bindings/display/bridge/rgb-to-vga-bridge.txt | 48 +++++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/sunxi_defconfig | 1 +
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/rgb-to-vga.c | 229 +++++++++++++++++++++
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 -
8 files changed, 341 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/rgb-to-vga-bridge.txt
create mode 100644 drivers/gpu/drm/bridge/rgb-to-vga.c
--
2.9.3
Maxime Ripard (5):
drm/sun4i: rgb: Remove the bridge enable/disable functions
drm/bridge: Add RGB to VGA bridge support
ARM: sun5i: a13-olinuxino: Enable VGA bridge
ARM: multi_v7: enable VGA bridge
ARM: sunxi: Enable VGA bridge
Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt | 48 +++++++++++++++-
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 +++++++++++++++++-
arch/arm/configs/multi_v7_defconfig | 1 +-
arch/arm/configs/sunxi_defconfig | 1 +-
drivers/gpu/drm/bridge/Kconfig | 7 ++-
drivers/gpu/drm/bridge/Makefile | 1 +-
drivers/gpu/drm/bridge/simple-vga-dac.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 +--
8 files changed, 341 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
create mode 100644 drivers/gpu/drm/bridge/simple-vga-dac.c
--
git-series 0.8.10
^ permalink raw reply
* [PATCH v6 1/5] drm/sun4i: rgb: Remove the bridge enable/disable functions
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
The atomic helpers already call the drm_bridge_enable on our behalf,
there's no need to do it a second time.
Reported-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/gpu/drm/sun4i/sun4i_rgb.c | 6 ------
1 file changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index 4e4bea6f395c..d198ad7e5323 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -155,9 +155,6 @@ static void sun4i_rgb_encoder_enable(struct drm_encoder *encoder)
if (!IS_ERR(tcon->panel))
drm_panel_prepare(tcon->panel);
- /* encoder->bridge can be NULL; drm_bridge_enable checks for it */
- drm_bridge_enable(encoder->bridge);
-
sun4i_tcon_channel_enable(tcon, 0);
if (!IS_ERR(tcon->panel))
@@ -177,9 +174,6 @@ static void sun4i_rgb_encoder_disable(struct drm_encoder *encoder)
sun4i_tcon_channel_disable(tcon, 0);
- /* encoder->bridge can be NULL; drm_bridge_disable checks for it */
- drm_bridge_disable(encoder->bridge);
-
if (!IS_ERR(tcon->panel))
drm_panel_unprepare(tcon->panel);
}
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 2/5] drm/bridge: Add RGB to VGA bridge support
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
Some boards have an entirely passive RGB to VGA bridge, based on either
DACs or resistor ladders.
Those might or might not have an i2c bus routed to the VGA connector in
order to access the screen EDIDs.
Add a bridge that doesn't do anything but expose the modes available on the
screen, either based on the EDIDs if available, or based on the XGA
standards.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt | 48 +++++++++++++++-
drivers/gpu/drm/bridge/Kconfig | 7 ++-
drivers/gpu/drm/bridge/Makefile | 1 +-
drivers/gpu/drm/bridge/simple-vga-dac.c | 229 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 285 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
create mode 100644 drivers/gpu/drm/bridge/simple-vga-dac.c
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
new file mode 100644
index 000000000000..7143c54ea88c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/simple-vga-dac.txt
@@ -0,0 +1,48 @@
+Dumb RGB to VGA bridge
+----------------------
+
+This binding is aimed for dumb RGB to VGA bridges that do not require
+any configuration.
+
+Required properties:
+
+- compatible: Must be "simple-vga-dac"
+
+Required nodes:
+
+This device has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for RGB input
+- Video port 1 for VGA output
+
+
+Example
+-------
+
+bridge {
+ compatible = "simple-vga-dac";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+};
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e678052d..5fe8c7829052 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -58,6 +58,13 @@ config DRM_SII902X
---help---
Silicon Image sii902x bridge chip driver.
+config DRM_SIMPLE_VGA_DAC
+ tristate "Simple VGA DAC support"
+ depends on OF
+ select DRM_KMS_HELPER
+ ---help---
+ Support for RGB to VGA bridges
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e878f5..2cdd99035f38 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SIMPLE_VGA_DAC) += simple-vga-dac.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/simple-vga-dac.c b/drivers/gpu/drm/bridge/simple-vga-dac.c
new file mode 100644
index 000000000000..c81a25ab0b0d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/simple-vga-dac.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2015-2016 Free Electrons
+ * Copyright (C) 2015-2016 NextThing Co
+ *
+ * Maxime Ripard <maxime.ripard@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/of_graph.h>
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc.h>
+#include <drm/drm_crtc_helper.h>
+
+struct simple_vga {
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_adapter *ddc;
+};
+
+static inline struct simple_vga *
+drm_bridge_to_simple_vga(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct simple_vga, bridge);
+}
+
+static inline struct simple_vga *
+drm_connector_to_simple_vga(struct drm_connector *connector)
+{
+ return container_of(connector, struct simple_vga, connector);
+}
+
+static int simple_vga_get_modes(struct drm_connector *connector)
+{
+ struct simple_vga *vga = drm_connector_to_simple_vga(connector);
+ struct edid *edid;
+ int ret;
+
+ if (IS_ERR(vga->ddc))
+ goto fallback;
+
+ edid = drm_get_edid(connector, vga->ddc);
+ if (!edid) {
+ DRM_INFO("EDID readout failed, falling back to standard modes\n");
+ goto fallback;
+ }
+
+ drm_mode_connector_update_edid_property(connector, edid);
+ return drm_add_edid_modes(connector, edid);
+
+fallback:
+ /*
+ * In case we cannot retrieve the EDIDs (broken or missing i2c
+ * bus), fallback on the XGA standards
+ */
+ ret = drm_add_modes_noedid(connector, 1920, 1200);
+
+ /* And prefer a mode pretty much anyone can handle */
+ drm_set_preferred_mode(connector, 1024, 768);
+
+ return ret;
+}
+
+static const struct drm_connector_helper_funcs simple_vga_con_helper_funcs = {
+ .get_modes = simple_vga_get_modes,
+};
+
+static enum drm_connector_status
+simple_vga_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct simple_vga *vga = drm_connector_to_simple_vga(connector);
+
+ /*
+ * Even if we have an I2C bus, we can't assume that the cable
+ * is disconnected if drm_probe_ddc fails. Some cables don't
+ * wire the DDC pins, or the I2C bus might not be working at
+ * all.
+ */
+ if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
+ return connector_status_connected;
+
+ return connector_status_unknown;
+}
+
+static void
+simple_vga_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs simple_vga_con_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .detect = simple_vga_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = simple_vga_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int simple_vga_attach(struct drm_bridge *bridge)
+{
+ struct simple_vga *vga = drm_bridge_to_simple_vga(bridge);
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Missing encoder\n");
+ return -ENODEV;
+ }
+
+ drm_connector_helper_add(&vga->connector,
+ &simple_vga_con_helper_funcs);
+ ret = drm_connector_init(bridge->dev, &vga->connector,
+ &simple_vga_con_funcs, DRM_MODE_CONNECTOR_VGA);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector\n");
+ return ret;
+ }
+
+ drm_mode_connector_attach_encoder(&vga->connector,
+ bridge->encoder);
+
+ return 0;
+}
+
+static const struct drm_bridge_funcs simple_vga_bridge_funcs = {
+ .attach = simple_vga_attach,
+};
+
+static struct i2c_adapter *simple_vga_retrieve_ddc(struct device *dev)
+{
+ struct device_node *end_node, *phandle, *remote;
+ struct i2c_adapter *ddc;
+
+ end_node = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
+ if (!end_node) {
+ dev_err(dev, "Missing connector endpoint\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ remote = of_graph_get_remote_port_parent(end_node);
+ of_node_put(end_node);
+ if (!remote) {
+ dev_err(dev, "Enable to parse remote node\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
+ of_node_put(remote);
+ if (!phandle)
+ return ERR_PTR(-ENODEV);
+
+ ddc = of_get_i2c_adapter_by_node(phandle);
+ of_node_put(phandle);
+ if (!ddc)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return ddc;
+}
+
+static int simple_vga_probe(struct platform_device *pdev)
+{
+ struct simple_vga *vga;
+ int ret;
+
+ vga = devm_kzalloc(&pdev->dev, sizeof(*vga), GFP_KERNEL);
+ if (!vga)
+ return -ENOMEM;
+ platform_set_drvdata(pdev, vga);
+
+ vga->ddc = simple_vga_retrieve_ddc(&pdev->dev);
+ if (IS_ERR(vga->ddc)) {
+ if (PTR_ERR(vga->ddc) == -ENODEV) {
+ dev_info(&pdev->dev,
+ "No i2c bus specified... Disabling EDID readout\n");
+ } else {
+ dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
+ return PTR_ERR(vga->ddc);
+ }
+ }
+
+ vga->bridge.funcs = &simple_vga_bridge_funcs;
+ vga->bridge.of_node = pdev->dev.of_node;
+
+ ret = drm_bridge_add(&vga->bridge);
+ if (ret && !IS_ERR(vga->ddc))
+ i2c_put_adapter(vga->ddc);
+
+ return ret;
+}
+
+static int simple_vga_remove(struct platform_device *pdev)
+{
+ struct simple_vga *vga = platform_get_drvdata(pdev);
+
+ drm_bridge_remove(&vga->bridge);
+
+ if (!IS_ERR(vga->ddc))
+ i2c_put_adapter(vga->ddc);
+
+ return 0;
+}
+
+static const struct of_device_id simple_vga_match[] = {
+ { .compatible = "simple-vga-dac" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, simple_vga_match);
+
+struct platform_driver simple_vga_driver = {
+ .probe = simple_vga_probe,
+ .remove = simple_vga_remove,
+ .driver = {
+ .name = "simple-vga-dac",
+ .of_match_table = simple_vga_match,
+ },
+};
+module_platform_driver(simple_vga_driver);
+
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_DESCRIPTION("Simple VGA DAC driver");
+MODULE_LICENSE("GPL");
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 3/5] ARM: sun5i: a13-olinuxino: Enable VGA bridge
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
Now that we have support for the VGA bridges using our DRM driver, enable
the display engine for the Olimex A13-Olinuxino.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 54 ++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index b3c234c65ea1..c69e0b0b7b55 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -72,6 +72,47 @@
default-state = "on";
};
};
+
+ bridge {
+ compatible = "simple-vga-dac";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+
+ vga_bridge_in: endpoint {
+ remote-endpoint = <&tcon0_out_vga>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+
+ vga_bridge_out: endpoint {
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
+};
+
+&be0 {
+ status = "okay";
};
&ehci0 {
@@ -211,6 +252,19 @@
status = "okay";
};
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+ status = "okay";
+};
+
+&tcon0_out {
+ tcon0_out_vga: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_b>;
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 4/5] ARM: multi_v7: enable VGA bridge
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
Enable the RGB to VGA bridge driver in the defconfig
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2c8665cd9dc5..ae1879a61bbe 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -567,6 +567,7 @@ CONFIG_DRM=y
CONFIG_DRM_I2C_ADV7511=m
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
+CONFIG_DRM_SIMPLE_VGA_DAC=m
CONFIG_DRM_NXP_PTN3460=m
CONFIG_DRM_PARADE_PS8622=m
CONFIG_DRM_NOUVEAU=m
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH v6 5/5] ARM: sunxi: Enable VGA bridge
From: Maxime Ripard @ 2016-10-06 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.2ec28e2292f37131839babc08427ef9f1aece26a.1475740611.git-series.maxime.ripard@free-electrons.com>
Enable the VGA bridge used on the A13-Olinuxino in the sunxi defconfig
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da336ec86..33b8c3308335 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -98,6 +98,7 @@ CONFIG_MEDIA_RC_SUPPORT=y
CONFIG_RC_DEVICES=y
CONFIG_IR_SUNXI=y
CONFIG_DRM=y
+CONFIG_DRM_SIMPLE_VGA_DAC=y
CONFIG_DRM_SUN4I=y
CONFIG_FB=y
CONFIG_FB_SIMPLE=y
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 02/11] DOCUMENTATION: dt-bindings: Document the STM32 USART bindings
From: Alexandre Torgue @ 2016-10-06 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqK=VCHcPbupnwLVEWehqJbXfGD1CSZT++A4+N6DD6VqxA@mail.gmail.com>
Hi Rob,
On 10/05/2016 05:13 PM, Rob Herring wrote:
> On Wed, Oct 5, 2016 at 9:09 AM, Gerald Baeza <gerald.baeza@st.com> wrote:
>> On 09/23/2016 05:29 PM, Rob Herring wrote:
>>>
>>> On Thu, Sep 15, 2016 at 06:42:34PM +0200, Alexandre TORGUE wrote:
>>>>
>>>> This adds documentation of device tree bindings for the
>>>> STM32 USART
>>>
>>>
>>> Please make your subject prefixes consistent and drop "DOCUMENTATION".
>>>
>>
>> Ok, thanks
>>
>>>>
>>>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>>> b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>>> new file mode 100644
>>>> index 0000000..75b1400
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/serial/st,stm32-usart.txt
>>>> @@ -0,0 +1,34 @@
>>>> +* STMicroelectronics STM32 USART
>>>> +
>>>> +Required properties:
>>>> +- compatible: Can be either "st,stm32-usart", "st,stm32-uart",
>>>> +"st,stm32f7-usart" or "st,stm32f7-uart" depending on whether
>>>> +the device supports synchronous mode and is compatible with
>>>> +stm32(f4) or stm32f7.
>>>
>>>
>>> Why not put f4 in the compatible string. stm32 is too generic.
>>
>>
>> The initial binding is not in current kernel so it has been put in this
>> serie as PATCH 07/11. It will be squashed with this one, as you requested.
>>
>> But the driver tty/serial/stm32-usart.c was already upstreamed and it
>> already mentions the "st,stm32-usart" and "st,stm32-uart" for stm32f4 so I
>> kept this as it for backward compatibility for those who already use the
>> driver.
>>
>> I do not have the history to explain this inconsistency but can you confirm
>> that keeping the existing compatible values from the driver is the good
>> approach please?
>
> Yes, keep it as it. Please reformat 1 valid combination per line.
Ok. Do you mean something like:
- compatible: "st,stm32-usart", "st,stm32-uart" For STM32F4 SOC and if
IP supports synchronous mode.
- compatible: "st,stm32-uart" For STM32F4 SOC.
- compatible: "st,stm32f7-usart", "st,stm32f7-uart": For STM32F7 SOC
and if IP supports synchronous mode.
- compatible: "st,stm32f7-uart" For STM32F7 SOC
If you agree, what do you prefer to send modification ? I mean, those
bindings documentation patches are already in linux-next tree. Do you
want a new patch on top of linux-next or do you prefer I resend only
those ones ?
Regards
Alex
>
>>> What determines sync mode or not? If it is IP configuration fixed in the
>>> design, then this is fine. If it is user choice or board dependent, then
>>> use a separate property.
>>
>>
>> This is IP configuration fixed in the design, indeed.
>>
>>>> +- reg: The address and length of the peripheral registers space
>>>> +- interrupts: The interrupt line of the USART instance
>>>> +- clocks: The input clock of the USART instance
>>>> +
>>>> +Optional properties:
>>>> +- pinctrl: The reference on the pins configuration
>>>> +- st,hw-flow-ctrl: bool flag to enable hardware flow control.
>>>> +
>>>> +Examples:
>>>> +usart4: serial at 40004c00 {
>>>> + compatible = "st,stm32-uart";
>>>> + reg = <0x40004c00 0x400>;
>>>> + interrupts = <52>;
>>>> + clocks = <&clk_pclk1>;
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&pinctrl_usart4>;
>>>> +};
>>>> +
>>>> +usart2: serial at 40004400 {
>>>> + compatible = "st,stm32-usart", "st,stm32-uart";
>>>
>>>
>>> What are valid combinations? usart is sync only, not sync and async?
>>
>>
>> usart (sync and async) is a superset of uart (async).
>> But the current driver does not use the synchronous mode, so the distinction
>> is just here to be consistent with the reference manual instances naming (so
>> configuration).
>
> Okay, but this point is not clear in the compatible text. The
> description should allow me to validate the example or a dts file.
>
> Rob
>
^ permalink raw reply
* [PATCH 3/8] PM / Domains: Allow domain power states to be read from DT
From: Geert Uytterhoeven @ 2016-10-06 8:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475699519-109623-4-git-send-email-lina.iyer@linaro.org>
Hi Lina,
On Wed, Oct 5, 2016 at 10:31 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> This patch allows domains to define idle states in the DT. SoC's can
> define domain idle states in DT using the "domain-idle-states" property
> of the domain provider. Calling of_pm_genpd_init() will read the idle
> states and initialize the genpd for the domain.
>
> In addition to the entry and exit latency for idle state, also add
> residency_ns, param and of_node property to each state. A domain idling
> in a state is only power effecient if it stays idle for a certain period
> in that state. The residency provides this minimum time for the idle
> state to provide power benefits. The param is a state specific u32 value
> that the platform may use for that idle state.
>
> This patch is based on the original patch by Marc Titinger.
>
> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> ---
> drivers/base/power/domain.c | 103 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pm_domain.h | 8 ++++
> 2 files changed, 111 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 740afa9..368a5b8 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1895,6 +1895,109 @@ out:
> return ret ? -EPROBE_DEFER : 0;
> }
> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
> +
> +static const struct of_device_id idle_state_match[] = {
> + { .compatible = "arm,idle-state", },
Do we want ARM-specific compatible values without an #ifdef in drivers/base/?
I know we already have "samsung,power-domain".
Perhaps that should be protected by #ifdef, too.
> + { }
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 5/8] dt/bindings: Update binding for PM domain idle states
From: Geert Uytterhoeven @ 2016-10-06 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475699519-109623-6-git-send-email-lina.iyer@linaro.org>
On Wed, Oct 5, 2016 at 10:31 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
> Update DT bindings to describe idle states of PM domains.
>
> This patch is based on the original patch by Marc Titinger.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../devicetree/bindings/power/power_domain.txt | 36 ++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 025b5e7..a043315 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -29,6 +29,10 @@ Optional properties:
> specified by this binding. More details about power domain specifier are
> available in the next section.
>
> +- domain-idle-states : A phandle of an idle-state that shall be soaked into a
> + generic domain power state. The idle state definitions are
> + compatible with arm,idle-state specified in [1].
> +
> Example:
>
> power: power-controller at 12340000 {
> @@ -59,6 +63,36 @@ The nodes above define two power controllers: 'parent' and 'child'.
> Domains created by the 'child' power controller are subdomains of '0' power
> domain provided by the 'parent' power controller.
>
> +Example 3:
> + parent: power-controller at 12340000 {
With W=1, this is gonna trigger:
Warning (unit_address_vs_reg): Node foo has a unit name, but no reg property
Yes, there are pre-existing users in this file.
> + compatible = "foo,power-controller";
> + reg = <0x12340000 0x1000>;
> + #power-domain-cells = <1>;
> + domain-idle-states = <&DOMAIN_RET, &DOMAIN_PWR_DN>;
> + };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 5/8] dt/bindings: Update binding for PM domain idle states
From: Geert Uytterhoeven @ 2016-10-06 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWxft8o493XN2zg1wj2By7P+qBkrvyQOt7WdBnhPAvSXQ@mail.gmail.com>
On Thu, Oct 6, 2016 at 10:06 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Wed, Oct 5, 2016 at 10:31 PM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Update DT bindings to describe idle states of PM domains.
>>
>> This patch is based on the original patch by Marc Titinger.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Marc Titinger <mtitinger+renesas@baylibre.com>
>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> .../devicetree/bindings/power/power_domain.txt | 36 ++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>> index 025b5e7..a043315 100644
>> --- a/Documentation/devicetree/bindings/power/power_domain.txt
>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>> @@ -29,6 +29,10 @@ Optional properties:
>> specified by this binding. More details about power domain specifier are
>> available in the next section.
>>
>> +- domain-idle-states : A phandle of an idle-state that shall be soaked into a
>> + generic domain power state. The idle state definitions are
>> + compatible with arm,idle-state specified in [1].
>> +
>> Example:
>>
>> power: power-controller at 12340000 {
>> @@ -59,6 +63,36 @@ The nodes above define two power controllers: 'parent' and 'child'.
>> Domains created by the 'child' power controller are subdomains of '0' power
>> domain provided by the 'parent' power controller.
>>
>> +Example 3:
>> + parent: power-controller at 12340000 {
>
> With W=1, this is gonna trigger:
>
> Warning (unit_address_vs_reg): Node foo has a unit name, but no reg property
>
> Yes, there are pre-existing users in this file.
Scrap this... switching desktops causes loss of position...
>> + compatible = "foo,power-controller";
>> + reg = <0x12340000 0x1000>;
>> + #power-domain-cells = <1>;
>> + domain-idle-states = <&DOMAIN_RET, &DOMAIN_PWR_DN>;
>> + };
+ DOMAIN_RET: state at 0 {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <10000>;
This one is gonna trigger
Warning (unit_address_vs_reg): Node foo has a unit name, but no reg property
+ };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Linus Walleij @ 2016-10-06 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgyh6at5.fsf@eliezer.anholt.net>
On Sat, Sep 24, 2016 at 9:01 AM, Eric Anholt <eric@anholt.net> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>> Sorry I am not familiar with your development model. I don't know
>> about any RPI downstream tree... What I mean is that the patch to
>> include/soc/bcm2835/raspberrypi-firmware.h should be merged by
>> whoever is maintaining that file, it is not a GPIO file.
>>
>> If I get an ACK from the maintainer I can take it into the GPIO
>> tree.
>
> Oh, people often say "the rpi tree" to mean downstream (currently 4.4).
> The maintainer of that file upstream is me, and I was hoping you could
> merge through your tree.
OK no problem, I can merge it once we agree on the mechanics :)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 4.7 050/141] irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning
From: Greg Kroah-Hartman @ 2016-10-06 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006074448.608056610@linuxfoundation.org>
4.7-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <james.morse@arm.com>
commit 727653d6ce7103b245eb8041f55dd5885f4c3289 upstream.
gic_raise_softirq() walks the list of cpus using for_each_cpu(), it calls
gic_compute_target_list() which advances the iterator by the number of
CPUs in the cluster.
If gic_compute_target_list() reaches the last CPU it leaves the iterator
pointing at the last CPU. This means the next time round the for_each_cpu()
loop cpumask_next() will be called with an invalid CPU.
This triggers a warning when built with CONFIG_DEBUG_PER_CPU_MAPS:
[ 3.077738] GICv3: CPU1: found redistributor 1 region 0:0x000000002f120000
[ 3.077943] CPU1: Booted secondary processor [410fd0f0]
[ 3.078542] ------------[ cut here ]------------
[ 3.078746] WARNING: CPU: 1 PID: 0 at ../include/linux/cpumask.h:121 gic_raise_softirq+0x12c/0x170
[ 3.078812] Modules linked in:
[ 3.078869]
[ 3.078930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc5+ #5188
[ 3.078994] Hardware name: Foundation-v8A (DT)
[ 3.079059] task: ffff80087a1a0080 task.stack: ffff80087a19c000
[ 3.079145] PC is at gic_raise_softirq+0x12c/0x170
[ 3.079226] LR is at gic_raise_softirq+0xa4/0x170
[ 3.079296] pc : [<ffff0000083ead24>] lr : [<ffff0000083eac9c>] pstate: 200001c9
[ 3.081139] Call trace:
[ 3.081202] Exception stack(0xffff80087a19fbe0 to 0xffff80087a19fd10)
[ 3.082269] [<ffff0000083ead24>] gic_raise_softirq+0x12c/0x170
[ 3.082354] [<ffff00000808e614>] smp_send_reschedule+0x34/0x40
[ 3.082433] [<ffff0000080e80a0>] resched_curr+0x50/0x88
[ 3.082512] [<ffff0000080e89d0>] check_preempt_curr+0x60/0xd0
[ 3.082593] [<ffff0000080e8a60>] ttwu_do_wakeup+0x20/0xe8
[ 3.082672] [<ffff0000080e8bb8>] ttwu_do_activate+0x90/0xc0
[ 3.082753] [<ffff0000080ea9a4>] try_to_wake_up+0x224/0x370
[ 3.082836] [<ffff0000080eabc8>] default_wake_function+0x10/0x18
[ 3.082920] [<ffff000008103134>] __wake_up_common+0x5c/0xa0
[ 3.083003] [<ffff0000081031f4>] __wake_up_locked+0x14/0x20
[ 3.083086] [<ffff000008103f80>] complete+0x40/0x60
[ 3.083168] [<ffff00000808df7c>] secondary_start_kernel+0x15c/0x1d0
[ 3.083240] [<00000000808911a4>] 0x808911a4
[ 3.113401] Detected PIPT I-cache on CPU2
Avoid updating the iterator if the next call to cpumask_next() would
cause the for_each_cpu() loop to exit.
There is no change to gic_raise_softirq()'s behaviour, (cpumask_next()s
eventual call to _find_next_bit() will return early as start >= nbits),
this patch just silences the warning.
Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3")
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Jason Cooper <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/1474306155-3303-1-git-send-email-james.morse at arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -558,7 +558,7 @@ static struct notifier_block gic_cpu_not
static u16 gic_compute_target_list(int *base_cpu, const struct cpumask *mask,
unsigned long cluster_id)
{
- int cpu = *base_cpu;
+ int next_cpu, cpu = *base_cpu;
unsigned long mpidr = cpu_logical_map(cpu);
u16 tlist = 0;
@@ -572,9 +572,10 @@ static u16 gic_compute_target_list(int *
tlist |= 1 << (mpidr & 0xf);
- cpu = cpumask_next(cpu, mask);
- if (cpu >= nr_cpu_ids)
+ next_cpu = cpumask_next(cpu, mask);
+ if (next_cpu >= nr_cpu_ids)
goto out;
+ cpu = next_cpu;
mpidr = cpu_logical_map(cpu);
^ permalink raw reply
* [PATCH 4.4 30/93] irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning
From: Greg Kroah-Hartman @ 2016-10-06 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006074731.150212126@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Morse <james.morse@arm.com>
commit 727653d6ce7103b245eb8041f55dd5885f4c3289 upstream.
gic_raise_softirq() walks the list of cpus using for_each_cpu(), it calls
gic_compute_target_list() which advances the iterator by the number of
CPUs in the cluster.
If gic_compute_target_list() reaches the last CPU it leaves the iterator
pointing at the last CPU. This means the next time round the for_each_cpu()
loop cpumask_next() will be called with an invalid CPU.
This triggers a warning when built with CONFIG_DEBUG_PER_CPU_MAPS:
[ 3.077738] GICv3: CPU1: found redistributor 1 region 0:0x000000002f120000
[ 3.077943] CPU1: Booted secondary processor [410fd0f0]
[ 3.078542] ------------[ cut here ]------------
[ 3.078746] WARNING: CPU: 1 PID: 0 at ../include/linux/cpumask.h:121 gic_raise_softirq+0x12c/0x170
[ 3.078812] Modules linked in:
[ 3.078869]
[ 3.078930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc5+ #5188
[ 3.078994] Hardware name: Foundation-v8A (DT)
[ 3.079059] task: ffff80087a1a0080 task.stack: ffff80087a19c000
[ 3.079145] PC is at gic_raise_softirq+0x12c/0x170
[ 3.079226] LR is at gic_raise_softirq+0xa4/0x170
[ 3.079296] pc : [<ffff0000083ead24>] lr : [<ffff0000083eac9c>] pstate: 200001c9
[ 3.081139] Call trace:
[ 3.081202] Exception stack(0xffff80087a19fbe0 to 0xffff80087a19fd10)
[ 3.082269] [<ffff0000083ead24>] gic_raise_softirq+0x12c/0x170
[ 3.082354] [<ffff00000808e614>] smp_send_reschedule+0x34/0x40
[ 3.082433] [<ffff0000080e80a0>] resched_curr+0x50/0x88
[ 3.082512] [<ffff0000080e89d0>] check_preempt_curr+0x60/0xd0
[ 3.082593] [<ffff0000080e8a60>] ttwu_do_wakeup+0x20/0xe8
[ 3.082672] [<ffff0000080e8bb8>] ttwu_do_activate+0x90/0xc0
[ 3.082753] [<ffff0000080ea9a4>] try_to_wake_up+0x224/0x370
[ 3.082836] [<ffff0000080eabc8>] default_wake_function+0x10/0x18
[ 3.082920] [<ffff000008103134>] __wake_up_common+0x5c/0xa0
[ 3.083003] [<ffff0000081031f4>] __wake_up_locked+0x14/0x20
[ 3.083086] [<ffff000008103f80>] complete+0x40/0x60
[ 3.083168] [<ffff00000808df7c>] secondary_start_kernel+0x15c/0x1d0
[ 3.083240] [<00000000808911a4>] 0x808911a4
[ 3.113401] Detected PIPT I-cache on CPU2
Avoid updating the iterator if the next call to cpumask_next() would
cause the for_each_cpu() loop to exit.
There is no change to gic_raise_softirq()'s behaviour, (cpumask_next()s
eventual call to _find_next_bit() will return early as start >= nbits),
this patch just silences the warning.
Fixes: 021f653791ad ("irqchip: gic-v3: Initial support for GICv3")
Signed-off-by: James Morse <james.morse@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: Jason Cooper <jason@lakedaemon.net>
Link: http://lkml.kernel.org/r/1474306155-3303-1-git-send-email-james.morse at arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -544,7 +544,7 @@ static struct notifier_block gic_cpu_not
static u16 gic_compute_target_list(int *base_cpu, const struct cpumask *mask,
unsigned long cluster_id)
{
- int cpu = *base_cpu;
+ int next_cpu, cpu = *base_cpu;
unsigned long mpidr = cpu_logical_map(cpu);
u16 tlist = 0;
@@ -558,9 +558,10 @@ static u16 gic_compute_target_list(int *
tlist |= 1 << (mpidr & 0xf);
- cpu = cpumask_next(cpu, mask);
- if (cpu >= nr_cpu_ids)
+ next_cpu = cpumask_next(cpu, mask);
+ if (next_cpu >= nr_cpu_ids)
goto out;
+ cpu = next_cpu;
mpidr = cpu_logical_map(cpu);
^ permalink raw reply
* [PATCH 1/8] PM / Domains: Make genpd state allocation dynamic
From: Ulf Hansson @ 2016-10-06 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475699519-109623-2-git-send-email-lina.iyer@linaro.org>
On 5 October 2016 at 22:31, Lina Iyer <lina.iyer@linaro.org> wrote:
> Allow PM Domain states to be defined dynamically by the drivers. This
> removes the limitation on the maximum number of states possible for a
> domain.
>
> Cc: Axel Haslam <ahaslam+renesas@baylibre.com>
> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> ---
> arch/arm/mach-imx/gpc.c | 17 ++++++++++-------
> drivers/base/power/domain.c | 10 ----------
> include/linux/pm_domain.h | 4 +---
> 3 files changed, 11 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
> index 0df062d..b92dad5 100644
> --- a/arch/arm/mach-imx/gpc.c
> +++ b/arch/arm/mach-imx/gpc.c
> @@ -380,13 +380,6 @@ static struct pu_domain imx6q_pu_domain = {
> .name = "PU",
> .power_off = imx6q_pm_pu_power_off,
> .power_on = imx6q_pm_pu_power_on,
> - .states = {
> - [0] = {
> - .power_off_latency_ns = 25000,
> - .power_on_latency_ns = 2000000,
> - },
> - },
> - .state_count = 1,
> },
> };
>
> @@ -430,6 +423,16 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
> if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
> return 0;
>
> + imx6q_pu_domain.base.states = devm_kzalloc(dev,
> + sizeof(*imx6q_pu_domain.base.states),
> + GFP_KERNEL);
> + if (!imx6q_pu_domain.base.states)
> + return -ENOMEM;
> +
> + imx6q_pu_domain.base.states[0].power_off_latency_ns = 25000;
> + imx6q_pu_domain.base.states[0].power_on_latency_ns = 2000000;
> + mx6q_pu_domain.base.state_count = 1,
> +
> pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
> return of_genpd_add_provider_onecell(dev->of_node,
> &imx_gpc_onecell_data);
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e023066..740afa9 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1325,16 +1325,6 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
> genpd->dev_ops.start = pm_clk_resume;
> }
>
> - if (genpd->state_idx >= GENPD_MAX_NUM_STATES) {
> - pr_warn("Initial state index out of bounds.\n");
> - genpd->state_idx = GENPD_MAX_NUM_STATES - 1;
> - }
> -
> - if (genpd->state_count > GENPD_MAX_NUM_STATES) {
> - pr_warn("Limiting states to %d\n", GENPD_MAX_NUM_STATES);
> - genpd->state_count = GENPD_MAX_NUM_STATES;
> - }
> -
> /* Use only one "off" state if there were no states declared */
> if (genpd->state_count == 0)
> genpd->state_count = 1;
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index a09fe5c..bd1ffb9 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -19,8 +19,6 @@
> /* Defines used for the flags field in the struct generic_pm_domain */
> #define GENPD_FLAG_PM_CLK (1U << 0) /* PM domain uses PM clk */
>
> -#define GENPD_MAX_NUM_STATES 8 /* Number of possible low power states */
> -
> enum gpd_status {
> GPD_STATE_ACTIVE = 0, /* PM domain is active */
> GPD_STATE_POWER_OFF, /* PM domain is off */
> @@ -70,7 +68,7 @@ struct generic_pm_domain {
> void (*detach_dev)(struct generic_pm_domain *domain,
> struct device *dev);
> unsigned int flags; /* Bit field of configs for genpd */
> - struct genpd_power_state states[GENPD_MAX_NUM_STATES];
> + struct genpd_power_state *states;
> unsigned int state_count; /* number of states */
> unsigned int state_idx; /* state that genpd will go to when off */
>
> --
> 2.7.4
>
In general I like the improvement, but..
This change implies that ->states may very well be NULL. This isn't
validated by genpd's internal logic when power off/on the domain
(genpd_power_on|off(), __default_power_down_ok()). You need to fix
this, somehow.
Perhaps the easiest solutions is, when pm_genpd_init() finds that
->state is NULL, that we allocate a struct genpd_power_state with
array size of 1 and assign it to ->states. Although, doing this also
means you need to track that genpd was responsible for the the
allocation, so it must also free the data from within genpd_remove().
Unless you have other ideas!?
Kind regards
Uffe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox