[PATCH v3 1/3] docs: arm: marvell: replace stale links with archive links
Marvell has an annoying habit of moving stuff around their web site every full moon, and often just removing documents altogether. At this point basically none but four of the links still works and even those that work today weren't working for a long period of time previously. That is a shame because (short of the product briefs) the documents tend to be quite useful. Let's replace them with known working versions of IA's Wayback Machine links. That seems to be about the only way of getting a URL that's going to work the next week. Signed-off-by: Lubomir Rintel --- Changes since v2: - Replace some more links instead of dropping them Changes since v1: - Adjust for removal of "[PATCH 0/4] docs: arm: marvell: turn the automatic links into labels" - Replace http URLs with https - Fix some more links Documentation/arm/marvell.rst | 156 +- 1 file changed, 79 insertions(+), 77 deletions(-) diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index 94cd733835942..796158e90334a 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -18,12 +18,12 @@ Orion family - 88F5181L - 88F5182 - - Datasheet: http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf - - Programmer's User Guide: http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf - - User Manual: http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf + - Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf + - Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf + - User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf - 88F5281 - - Datasheet: http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf + - Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf - 88F6183 Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible @@ -38,33 +38,33 @@ Kirkwood family Flavors: - 88F6282 a.k.a Armada 300 -- Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +- Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf - 88F6283 a.k.a Armada 310 -- Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +- Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf - 88F6190 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : https://web.archive.org/web/20130730072715/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf +- Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf +- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - 88F6192 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : https://web.archive.org/web/20131113121446/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf +- Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf +- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - 88F6182 - 88F6180 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-00
[PATCH v3 2/3] docs: arm: marvell: drop a dead links
This one has gone away. Remove it; there's good chance there wasn't anything useful there anyway. Signed-off-by: Lubomir Rintel --- Changes since v2: - Just remove one link; the rest has been replaced with archive links Changes since v1: - Adjust for removal of "[PATCH 0/4] docs: arm: marvell: turn the automatic links into labels" - Split off the hunk that fixes 38x functional spec link Documentation/arm/marvell.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index 796158e90334a..615dd8a13807a 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -399,7 +399,6 @@ Berlin family (Multimedia Solutions) - Flavors: - 88DE3010, Armada 1000 (no Linux support) - Core: Marvell PJ1 (ARMv5TE), Dual-core - - Product Brief: http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf - 88DE3005, Armada 1500 Mini - Design name: BG2CD - Core: ARM Cortex-A9, PL310 L2CC -- 2.29.2
[PATCH v3 3/3] docs: arm: marvell: clarify some unimportant Armada 6x0 details
MMP2 is used in XO-1.75 and MMP3 is now supported in mainline. Signed-off-by: Lubomir Rintel --- Documentation/arm/marvell.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index 615dd8a13807a..7f96068a9eae2 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -356,13 +356,12 @@ MMP/MMP2/MMP3 family (communication processor) - Product Brief: https://archive.org/download/marvell-pxa910-pb/Marvell_PXA910_Platform-001_PB.pdf - Application processor with Communication processor - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) -- PXA688, a.k.a. MMP2, a.k.a Armada 610 +- PXA688, a.k.a. MMP2, a.k.a Armada 610 (OLPC XO-1.75) - Product Brief: https://web.archive.org/web/2002023255/http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf - Application processor only - Core: ARMv7 compatible Sheeva PJ4 88sv581x core - - PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream) + - PXA2128, a.k.a. MMP3, a.k.a Armada 620 (OLPC XO-4) - Product Brief: https://web.archive.org/web/20120824055155/http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf - - Application processor only - Core: Dual-core ARMv7 compatible Sheeva PJ4C core - PXA960/PXA968/PXA978 (Linux support not upstream) -- 2.29.2
[PATCH v3 0/3] docs: arm: Improvements to Marvell SoC documentation
Hi, please consider applying the patches chained to this message. The objective is to deal with the a large amount of dead links to material that often comes handy in marvel.rst; and improve some details along the way. Compared to v2, the patches "[PATCH v2 2/5] docs: arm: marvell: fix 38x functional spec link" and "[PATCH v2 5/5] docs: arm: marvell: rename marvel.rst to marvell.rst" have been removed, because analogous patches have already been applied. Also, more dead links have been removed, reducing the count of links removed in [PATCH v3 1/3] to one. Detailed changelogs in individual patches. Thank you Lubo
[PATCH 0/1] clk: mmp2: Enable the 3D GPU clock alongside the 2D clock
Hi, Please consider applying the sad little patch chained to this message. It is a workaround that makes the 2D GPU work on MMP3 when the 3D GPU is not used. It's been observed that the 2D GPU won't work when what is understood to be the 3D GPU clock is turned off. The etnaviv developers suggest [1][2] that perhaps said understanding is wrong and they may be right. Unfortunately no documentation is available, all we know is the register names. In any case it seems to make more sense to put the workaround in the MMP clock driver instead of to the etnaviv driver. [1] https://lists.freedesktop.org/archives/etnaviv/2020-November/003442.html [2] https://lists.freedesktop.org/archives/etnaviv/2020-December/003445.html Thanks Lubo
[PATCH 1/1] clk: mmp2: Enable the 3D GPU clock alongside the 2D clock
The bits intended to control the 3D GPU clock need to be enabled for the
2D GPU to work. It is not clear why this needs to be done.
Forcing the 3D clock on when the etnaviv driver requests a 2D clock
works around the problem.
Signed-off-by: Lubomir Rintel
---
drivers/clk/mmp/clk-gate.c| 9 -
drivers/clk/mmp/clk-of-mmp2.c | 2 +-
drivers/clk/mmp/clk.c | 3 ++-
drivers/clk/mmp/clk.h | 10 +-
4 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mmp/clk-gate.c b/drivers/clk/mmp/clk-gate.c
index 1755916ddef2d..bf93ffb258667 100644
--- a/drivers/clk/mmp/clk-gate.c
+++ b/drivers/clk/mmp/clk-gate.c
@@ -9,6 +9,7 @@
* warranty of any kind, whether express or implied.
*/
+#include
#include
#include
#include
@@ -31,6 +32,8 @@ static int mmp_clk_gate_enable(struct clk_hw *hw)
unsigned long rate;
u32 tmp;
+ clk_prepare_enable(gate->companion);
+
if (gate->lock)
spin_lock_irqsave(gate->lock, flags);
@@ -67,6 +70,8 @@ static void mmp_clk_gate_disable(struct clk_hw *hw)
if (gate->lock)
spin_unlock_irqrestore(gate->lock, flags);
+
+ clk_disable_unprepare(gate->companion);
}
static int mmp_clk_gate_is_enabled(struct clk_hw *hw)
@@ -95,7 +100,8 @@ const struct clk_ops mmp_clk_gate_ops = {
struct clk *mmp_clk_register_gate(struct device *dev, const char *name,
const char *parent_name, unsigned long flags,
void __iomem *reg, u32 mask, u32 val_enable, u32 val_disable,
- unsigned int gate_flags, spinlock_t *lock)
+ unsigned int gate_flags, spinlock_t *lock,
+ struct clk *companion)
{
struct mmp_clk_gate *gate;
struct clk *clk;
@@ -119,6 +125,7 @@ struct clk *mmp_clk_register_gate(struct device *dev, const
char *name,
gate->val_disable = val_disable;
gate->flags = gate_flags;
gate->lock = lock;
+ gate->companion = companion;
gate->hw.init =
clk = clk_register(dev, >hw);
diff --git a/drivers/clk/mmp/clk-of-mmp2.c b/drivers/clk/mmp/clk-of-mmp2.c
index 8b2eb989980bf..7ac96a1dcd60c 100644
--- a/drivers/clk/mmp/clk-of-mmp2.c
+++ b/drivers/clk/mmp/clk-of-mmp2.c
@@ -394,7 +394,7 @@ static struct mmp_param_gate_clk mmp2_apmu_gate_clks[] = {
static struct mmp_param_gate_clk mmp3_apmu_gate_clks[] = {
{MMP3_CLK_SDH4, "sdh4_clk", "sdh_mix_clk", CLK_SET_RATE_PARENT,
APMU_SDH4, 0x1b, 0x1b, 0x0, 0, _lock},
{MMP3_CLK_GPU_3D, "gpu_3d_clk", "gpu_3d_div", CLK_SET_RATE_PARENT,
APMU_GPU, 0x5, 0x5, 0x0, MMP_CLK_GATE_NEED_DELAY, _lock},
- {MMP3_CLK_GPU_2D, "gpu_2d_clk", "gpu_2d_div", CLK_SET_RATE_PARENT,
APMU_GPU, 0x1c, 0x1c, 0x0, MMP_CLK_GATE_NEED_DELAY, _lock},
+ {MMP3_CLK_GPU_2D, "gpu_2d_clk", "gpu_2d_div", CLK_SET_RATE_PARENT,
APMU_GPU, 0x1c, 0x1c, 0x0, MMP_CLK_GATE_NEED_DELAY, _lock,
MMP3_CLK_GPU_3D},
};
static void mmp2_axi_periph_clk_init(struct mmp2_clk_unit *pxa_unit)
diff --git a/drivers/clk/mmp/clk.c b/drivers/clk/mmp/clk.c
index ca7d37e2c7be6..05d2b901cae5f 100644
--- a/drivers/clk/mmp/clk.c
+++ b/drivers/clk/mmp/clk.c
@@ -109,7 +109,8 @@ void mmp_register_gate_clks(struct mmp_clk_unit *unit,
clks[i].val_enable,
clks[i].val_disable,
clks[i].gate_flags,
- clks[i].lock);
+ clks[i].lock,
+ unit->clk_table[clks[i].companion_id]);
if (IS_ERR(clk)) {
pr_err("%s: failed to register clock %s\n",
diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h
index 55ac053797819..385b74e671c31 100644
--- a/drivers/clk/mmp/clk.h
+++ b/drivers/clk/mmp/clk.h
@@ -117,6 +117,13 @@ struct mmp_clk_gate {
u32 val_disable;
unsigned int flags;
spinlock_t *lock;
+
+ /*
+* The sole purpose of this is to make sure the 3D GPU clock gets
+* enabled alongside 2D GPU clock, otherwise the 2D unit wouldn't
+* work. It is not know why this needs to be done.
+*/
+ struct clk *companion;
};
extern const struct clk_ops mmp_clk_gate_ops;
@@ -124,7 +131,7 @@ extern struct clk *mmp_clk_register_gate(struct device
*dev, const char *name,
const char *parent_name, unsigned long flags,
void __iomem *reg, u32 mask, u32 val_enable,
u32 val_disable, unsigned int gate_flags,
- spinlock_t *lock);
+ spinlock_t *lock, struct clk *companion);
extern struct clk *mmp_clk_register_apbc(const char *name,
const char *parent_n
[PATCH v2 3/5] docs: arm: marvell: replace stale links with archive links
Marvell has an annoying habit of moving stuff around their web site every full moon, and often just removing documents altogether. At this point basically none but four of the links still works and even those that work today weren't working for a long period of time previously. That is a shame because (short of the product briefs) the documents tend to be quite useful. Let's replace them with known working versions of IA's Wayback Machine links. That seems to be about the only way of getting a URL that's going to work the next week. Signed-off-by: Lubomir Rintel --- Changes since v1: - Adjust for removal of "[PATCH 1/5] docs: arm: marvell: turn the automatic links into labels" - Replace http URLs with https - Fix some more links Documentation/arm/marvel.rst | 130 ++- 1 file changed, 66 insertions(+), 64 deletions(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index ab0c38dc108a8..bcf3f4e3e8faf 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -18,12 +18,12 @@ Orion family - 88F5181L - 88F5182 - - Datasheet: http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf - - Programmer's User Guide: http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf - - User Manual: http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf + - Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf + - Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf + - User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf - 88F5281 - - Datasheet: http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf + - Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf - 88F6183 Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible @@ -38,31 +38,31 @@ Kirkwood family Flavors: - 88F6282 a.k.a Armada 300 -- Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +- Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf - 88F6283 a.k.a Armada 310 -- Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +- Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf - 88F6190 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : https://web.archive.org/web/20130730072715/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf +- Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf +- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - 88F6192 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : https://web.archive.org/web/20131113121446/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf +- Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf +- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - 88F6182 - 88F6180 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf -- Hardware Spec : http://www.marvell.co
[PATCH v2 0/5] docs: arm: Improvements to Marvell SoC documentation
Hi, please consider applying the patches chained to this message. The objective is to deal with the a large amount of dead links to material that often comes handy in marvel.rst; and improve some details along the way. The most important change since v1 is the removal of "[PATCH 1/5] docs: arm: marvell: turn the automatic links into labels" patch and replacing the URLs inline instead. Detailed changelogs in individual patches. Thank you Lubo
[PATCH v2 2/5] docs: arm: marvell: fix 38x functional spec link
This one went away, but the document is still available. Signed-off-by: Lubomir Rintel --- Changes since v1: - Split this off from "[PATCH] docs: arm: marvell: drop some dead links" Documentation/arm/marvel.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index 502a1b89a2c85..ab0c38dc108a8 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -124,7 +124,7 @@ EBU Armada family - 88F6820 Armada 385 - 88F6828 Armada 388 -- Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/ +- Functional Spec: https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf Core: ARM Cortex-A9 -- 2.29.2
[PATCH v2 4/5] docs: arm: marvell: clarify some unimportant Armada 6x0 details
MMP2 is used in XO-1.75 and MMP3 is now supported in mainline. Signed-off-by: Lubomir Rintel --- Documentation/arm/marvel.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index bcf3f4e3e8faf..d83917f226376 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -329,13 +329,12 @@ MMP/MMP2/MMP3 family (communication processor) - Product Brief: https://archive.org/download/marvell-pxa910-pb/Marvell_PXA910_Platform-001_PB.pdf - Application processor with Communication processor - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) -- PXA688, a.k.a. MMP2, a.k.a Armada 610 +- PXA688, a.k.a. MMP2, a.k.a Armada 610 (OLPC XO-1.75) - Product Brief: https://web.archive.org/web/2002023255/http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf - Application processor only - Core: ARMv7 compatible Sheeva PJ4 88sv581x core - - PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream) + - PXA2128, a.k.a. MMP3, a.k.a Armada 620 (OLPC XO-4) - Product Brief: https://web.archive.org/web/20120824055155/http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf - - Application processor only - Core: Dual-core ARMv7 compatible Sheeva PJ4C core - PXA960/PXA968/PXA978 (Linux support not upstream) -- 2.29.2
[PATCH v2 1/5] docs: arm: marvell: drop some dead links
Just remove these; there's good chance there wasn't anything useful there anyway. Signed-off-by: Lubomir Rintel --- Changes since v1: - Adjust for removal of "[PATCH 1/5] docs: arm: marvell: turn the automatic links into labels" - Split off the hunk that fixes 38x functional spec link Documentation/arm/marvel.rst | 25 - 1 file changed, 25 deletions(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index 16ab2eb085b86..502a1b89a2c85 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -63,8 +63,6 @@ Kirkwood family - Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf - Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf - Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - Homepage: - http://www.marvell.com/embedded-processors/kirkwood/ Core: Feroceon 88fr131 ARMv5 compatible Linux kernel mach directory: @@ -126,7 +124,6 @@ EBU Armada family - 88F6820 Armada 385 - 88F6828 Armada 388 -- Product infos: http://www.marvell.com/embedded-processors/armada-38x/ - Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/ Core: @@ -136,8 +133,6 @@ EBU Armada family - 88F6920 Armada 390 - 88F6928 Armada 398 -- Product infos: http://www.marvell.com/embedded-processors/armada-39x/ - Core: ARM Cortex-A9 @@ -179,9 +174,6 @@ EBU Armada family ARMv8 Core: ARM Cortex A53 (ARMv8) - Homepage: - http://www.marvell.com/embedded-processors/armada-3700/ - Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf @@ -194,9 +186,6 @@ EBU Armada family ARMv8 Core: ARM Cortex A72 - Homepage: - http://www.marvell.com/embedded-processors/armada-70xx/ - Product Brief: - http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf - http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf @@ -210,9 +199,6 @@ EBU Armada family ARMv8 Core: ARM Cortex A72 - Homepage: - http://www.marvell.com/embedded-processors/armada-80xx/ - Product Brief: - http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf - http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf @@ -229,9 +215,6 @@ Avanta family - 88F6550 - 88F6560 - Homepage: - http://www.marvell.com/broadband/ - Product Brief: http://www.marvell.com/broadband/assets/Marvell_Avanta_88F6510_305_060-001_product_brief.pdf @@ -251,9 +234,6 @@ Storage family Armada SP: - 88RC1580 - Product infos: - http://www.marvell.com/storage/armada-sp/ - Core: Sheeva ARMv7 comatible Quad-core PJ4C @@ -274,9 +254,6 @@ Dove family (application processor) Functional Spec: http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf - Homepage: - http://www.marvell.com/application-processors/armada-500/ - Core: ARMv7 compatible @@ -348,7 +325,6 @@ MMP/MMP2/MMP3 family (communication processor) - Application processor only - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) - PXA910/PXA920 - - Homepage : http://www.marvell.com/communication-processors/pxa910/ - Product Brief: http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf - Application processor with Communication processor - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) @@ -394,7 +370,6 @@ Berlin family (Multimedia Solutions) - Flavors: - 88DE3010, Armada 1000 (no Linux support) - Core: Marvell PJ1 (ARMv5TE), Dual-core - - Product Brief: http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf - 88DE3005, Armada 1500 Mini - Design name: BG2CD - Core: ARM Cortex-A9, PL310 L2CC -- 2.29.2
[PATCH v2 5/5] docs: arm: marvell: rename marvel.rst to marvell.rst
This company is not the superheroes you're looking for.
Signed-off-by: Lubomir Rintel
---
Documentation/arm/{marvel.rst => marvell.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/arm/{marvel.rst => marvell.rst} (100%)
diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvell.rst
similarity index 100%
rename from Documentation/arm/marvel.rst
rename to Documentation/arm/marvell.rst
--
2.29.2
Re: ARM: dts: mmp devicetree updates
On Tue, Feb 02, 2021 at 06:13:18PM +0100, Arnd Bergmann wrote: > On Tue, Feb 2, 2021 at 5:41 PM Arnd Bergmann wrote: > > > > On Fri, Jan 22, 2021 at 3:09 PM Arnd Bergmann wrote: > > > On Thu, Jan 21, 2021 at 4:41 AM Lubomir Rintel wrote: > > > > > > > > chained to this message is a handful of patches related to MMP device > > > > trees and bindings. Please take a look and consider queueing them for > > > > for 5.12. > > > > > > These all look good to me, but I notice that a lot of them seem to be > > > bugfixes, so please have another look and decide if any of them should > > > go into v5.11 and perhaps backported to stable kernels as well. > > > > Hi Lubomir, > > > > not sure if you missed my earlier mail. To clarify, I have not applied > > any of the patches so far. Can you recheck if some of them should be > > part of the v5.11 release so I know which tree to apply them to? > > Nevermind, I just found your earlier reply in my spam folder. Applying > the patches now. Would you mind sharing why your spam filter decided to flag my message? (the X-Spam* headers, if there's anything relevant there). I'm wondering if it's possible other spam filters drop my messages for the same reason and if it's something I could fix. Thank you. Lubo > > Arnd
Re: [PATCH 1/5] docs: arm: marvell: turn the automatic links into labels
On Fri, Jan 29, 2021 at 05:20:28PM -0700, Jonathan Corbet wrote: > Lubomir Rintel writes: > > > Lines ending with obscenely long URLs at the end don't look good. > > > > Even if these links are not that long at this point, they will be when > > replaced with an archive link in a subsequent patch -- let's prepare for > > that. > > > > Signed-off-by: Lubomir Rintel > > --- > > Documentation/arm/marvel.rst | 209 --- > > 1 file changed, 143 insertions(+), 66 deletions(-) > > > > diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst > > index 16ab2eb085b86..716551f9b60a1 100644 > > --- a/Documentation/arm/marvel.rst > > +++ b/Documentation/arm/marvel.rst > > @@ -18,12 +18,12 @@ Orion family > > - 88F5181L > > - 88F5182 > > > > - - Datasheet: > > http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf > > - - Programmer's User Guide: > > http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf > > - - User Manual: > > http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf > > + - Datasheet: `MV88F5182-datasheet.pdf`_ > > + - Programmer's User Guide: > > `MV88F5182-opensource-manual.pdf`_ > > + - User Manual: `MV88F5182-usermanual.pdf`_ > > - 88F5281 > > > > - - Datasheet: > > http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf > > + - Datasheet: `marvel_88f5281_data_sheet.pdf`_ > > - 88F6183 > >Core: > > Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible > > @@ -32,37 +32,42 @@ Orion family > >Linux kernel plat directory: > > arch/arm/plat-orion > > > > +.. _MV88F5182-datasheet.pdf: > > http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf > > +.. _MV88F5182-opensource-manual.pdf: > > http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf > > +.. _MV88F5182-usermanual.pdf: > > http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf > > +.. _marvel_88f5281_data_sheet.pdf: > > http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf > > So I see what you're trying to do, but this has the effect of prettying > up the processed docs at the expense of making the plain-text version > harder to read. Somebody who wants to find one of these datasheets from > the plain-text version has to skip further down in the file, hoping that > they pick out the right one among a set of long, similar URLs. > Honestly, I think we may be better off leaving them as they are. > Failing that, the right thing to do is to keep the lines defining the > URL labels right next to where they are referenced. > > See what I'm getting at? Yes. I've been considering the same, but concluded it's a still a better idea to move the full URLs below because 1.) at this point the links are broken anyway and the basename is the only valuable part of the URL when looking for an actual document; and the basename stays in place 2.) the archive.org links that replace them in another patch are wy too long even for very large displays However, even though I think this is perhaps marginally better, either way works for me. Thus, unless you change your mind about it, I'll follow up with a v2 that drops this patch and replaces the links in place. Thank you Lubo > > Thanks, > > jon
Re: ARM: dts: mmp devicetree updates
On Fri, Jan 22, 2021 at 03:09:14PM +0100, Arnd Bergmann wrote: > On Thu, Jan 21, 2021 at 4:41 AM Lubomir Rintel wrote: > > > > Hi, > > > > chained to this message is a handful of patches related to MMP device > > trees and bindings. Please take a look and consider queueing them for > > for 5.12. > > These all look good to me, but I notice that a lot of them seem to be > bugfixes, so please have another look and decide if any of them should > go into v5.11 and perhaps backported to stable kernels as well. I'm not sure any of these are worth backporting to stable. I believe actually only these two are bugfixes: [PATCH 06/12] ARM: dts: mmp3: Extend the MPMU reg range [PATCH 12/12] ARM: dts: mmp3: Fix the CCIC interrupts The first one only affects the audio, but the MMP I2S driver doesn't work on MMP3 yet. The second one affects the camera, but the only board DTS shipped at this point doesn't have one. Therefore both are somewhat inconequential for older kernels. > >Arnd Thanks Lubo
[PATCH 3/5] docs: arm: marvell: replace stale links with archive links
Marvell has an annoying habit of moving stuff around their web site every full moon, and often just removing documents altogether. At this point basically none but four of the links still works and even those that work today weren't working for a long period of time previously. That is a shame because (short of the product briefs) the documents tend to be quite useful. Let's replace them with known working versions of IA's Wayback Machine links. That seems to be about the only way of getting a URL that's going to work the next week. Signed-off-by: Lubomir Rintel --- Documentation/arm/marvel.rst | 76 ++-- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index 8577f8324f6c7..0c291d1091f1d 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -32,10 +32,10 @@ Orion family Linux kernel plat directory: arch/arm/plat-orion -.. _MV88F5182-datasheet.pdf: http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf -.. _MV88F5182-opensource-manual.pdf: http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf -.. _MV88F5182-usermanual.pdf: http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf -.. _marvel_88f5281_data_sheet.pdf: http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf +.. _MV88F5182-datasheet.pdf: http://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf +.. _MV88F5182-opensource-manual.pdf: http://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf +.. _MV88F5182-usermanual.pdf: http://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf +.. _marvel_88f5281_data_sheet.pdf: http://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf Kirkwood family --- @@ -75,18 +75,18 @@ Kirkwood family Linux kernel plat directory: none -.. _armada_310.pdf: http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf -.. _armada_310.pdf: http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +.. _armada_310.pdf: http://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +.. _armada_310.pdf: http://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf .. _88F6190-003_WEB.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf -.. _HW_88F619x_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf +.. _HW_88F619x_OpenSource.pdf: http://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf .. _FS_88F6180_9x_6281_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf -.. _88F6192-003_ver1.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf -.. _HW_88F619x_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf +.. _88F6192-003_ver1.pdf: http://web.archive.org/web/20131113121446/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf +.. _HW_88F619x_OpenSource.pdf: http://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf .. _FS_88F6180_9x_6281_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf .. _88F6180-003_ver1.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf .. _HW_88F6180_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf .. _FS_88F6180_9x_6281_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf -.. _88F6281-004_ver1.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf +.. _88F6281-004_ver1.pdf: http://web.archive.org/web/20120131133709/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf .. _HW_88F6281_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf .. _FS_88F6180_9x_6281_OpenSource.pdf: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf @@ -116,10 +116,10 @@ Discovery family Linux kernel plat directory: arch/arm/plat-orion -.. _MV78100-003_WEB.pdf: http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf -.. _HW_MV78100_OpenSource.pdf: http://www.marvell.com/embedded
[PATCH 4/5] docs: arm: marvell: clarify some unimportant Armada 6x0 details
MMP2 is used in XO-1.75 and MMP3 is now supported in mainline. Signed-off-by: Lubomir Rintel --- Documentation/arm/marvel.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index 0c291d1091f1d..43f2fe407796e 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -392,11 +392,11 @@ MMP/MMP2/MMP3 family (communication processor) - Product Brief: `Marvell_PXA910_Platform-001_PB_final.pdf`_ - Application processor with Communication processor - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) -- PXA688, a.k.a. MMP2, a.k.a Armada 610 +- PXA688, a.k.a. MMP2, a.k.a Armada 610 (OLPC XO-1.75) - Product Brief: `armada610_pb.pdf`_ - Application processor only - Core: ARMv7 compatible Sheeva PJ4 88sv581x core - - PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream) + - PXA2128, a.k.a. MMP3, a.k.a Armada 620 (OLPC XO-4) - Product Brief : `Marvell-ARMADA-PXA2128-SoC-PB.pdf`_ - Application processor only - Core: Dual-core ARMv7 compatible Sheeva PJ4C core -- 2.29.2
[PATCH 1/5] docs: arm: marvell: turn the automatic links into labels
Lines ending with obscenely long URLs at the end don't look good. Even if these links are not that long at this point, they will be when replaced with an archive link in a subsequent patch -- let's prepare for that. Signed-off-by: Lubomir Rintel --- Documentation/arm/marvel.rst | 209 --- 1 file changed, 143 insertions(+), 66 deletions(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index 16ab2eb085b86..716551f9b60a1 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -18,12 +18,12 @@ Orion family - 88F5181L - 88F5182 - - Datasheet: http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf - - Programmer's User Guide: http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf - - User Manual: http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf + - Datasheet: `MV88F5182-datasheet.pdf`_ + - Programmer's User Guide: `MV88F5182-opensource-manual.pdf`_ + - User Manual: `MV88F5182-usermanual.pdf`_ - 88F5281 - - Datasheet: http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf + - Datasheet: `marvel_88f5281_data_sheet.pdf`_ - 88F6183 Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible @@ -32,37 +32,42 @@ Orion family Linux kernel plat directory: arch/arm/plat-orion +.. _MV88F5182-datasheet.pdf: http://www.embeddedarm.com/documentation/third-party/MV88F5182-datasheet.pdf +.. _MV88F5182-opensource-manual.pdf: http://www.embeddedarm.com/documentation/third-party/MV88F5182-opensource-manual.pdf +.. _MV88F5182-usermanual.pdf: http://www.embeddedarm.com/documentation/third-party/MV88F5182-usermanual.pdf +.. _marvel_88f5281_data_sheet.pdf: http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf + Kirkwood family --- Flavors: - 88F6282 a.k.a Armada 300 -- Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +- Product Brief : `armada_310.pdf`_ - 88F6283 a.k.a Armada 310 -- Product Brief : http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf +- Product Brief : `armada_310.pdf`_ - 88F6190 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : `88F6190-003_WEB.pdf`_ +- Hardware Spec : `HW_88F619x_OpenSource.pdf`_ +- Functional Spec: `FS_88F6180_9x_6281_OpenSource.pdf`_ - 88F6192 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : `88F6192-003_ver1.pdf`_ +- Hardware Spec : `HW_88F619x_OpenSource.pdf`_ +- Functional Spec: `FS_88F6180_9x_6281_OpenSource.pdf`_ - 88F6182 - 88F6180 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : `88F6180-003_ver1.pdf`_ +- Hardware Spec : `HW_88F6180_OpenSource.pdf`_ +- Functional Spec: `FS_88F6180_9x_6281_OpenSource.pdf`_ - 88F6281 -- Product Brief : http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf -- Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf -- Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf +- Product Brief : `88F6281-004_ver1.pdf`_ +- Hardware Spec : `HW_88F6281_OpenSource.pdf`_ +- Functional Spec: `FS_88F6180_9x_6281_OpenSource.pdf`_ Homepage: http://www.marvell.com/embedded-processors/kirkwood/ Core: @@ -72,20 +77,35 @@ Kirkwood
[PATCH 2/5] docs: arm: marvell: drop some dead links
Just remove these; there's good chance there wasn't anything useful there anyway. Signed-off-by: Lubomir Rintel --- Documentation/arm/marvel.rst | 27 ++- 1 file changed, 2 insertions(+), 25 deletions(-) diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvel.rst index 716551f9b60a1..8577f8324f6c7 100644 --- a/Documentation/arm/marvel.rst +++ b/Documentation/arm/marvel.rst @@ -68,8 +68,6 @@ Kirkwood family - Product Brief : `88F6281-004_ver1.pdf`_ - Hardware Spec : `HW_88F6281_OpenSource.pdf`_ - Functional Spec: `FS_88F6180_9x_6281_OpenSource.pdf`_ - Homepage: - http://www.marvell.com/embedded-processors/kirkwood/ Core: Feroceon 88fr131 ARMv5 compatible Linux kernel mach directory: @@ -153,8 +151,7 @@ EBU Armada family - 88F6820 Armada 385 - 88F6828 Armada 388 -- Product infos: http://www.marvell.com/embedded-processors/armada-38x/ -- Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/ +- Functional Spec: `marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf`_ Core: ARM Cortex-A9 @@ -163,8 +160,6 @@ EBU Armada family - 88F6920 Armada 390 - 88F6928 Armada 398 -- Product infos: http://www.marvell.com/embedded-processors/armada-39x/ - Core: ARM Cortex-A9 @@ -200,6 +195,7 @@ EBU Armada family .. _ARMADA370-datasheet.pdf: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf .. _ARMADA370-FunctionalSpec-datasheet.pdf: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf .. _ARMADA_375_SoC-01_product_brief.pdf: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf +.. _marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf: https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf .. _Marvell-ArmadaXP-SoC-product%20brief.pdf: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf .. _ARMADA-XP-Functional-SpecDatasheet.pdf: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf .. _HW_MV78230_OS.PDF: http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF @@ -216,9 +212,6 @@ EBU Armada family ARMv8 Core: ARM Cortex A53 (ARMv8) - Homepage: - http://www.marvell.com/embedded-processors/armada-3700/ - Product Brief: `PB-88F3700-FNL.pdf`_ @@ -231,9 +224,6 @@ EBU Armada family ARMv8 Core: ARM Cortex A72 - Homepage: - http://www.marvell.com/embedded-processors/armada-70xx/ - Product Brief: - `Armada7020PB-Jan2016.pdf`_ - `Armada7040PB-Jan2016.pdf`_ @@ -247,9 +237,6 @@ EBU Armada family ARMv8 Core: ARM Cortex A72 - Homepage: - http://www.marvell.com/embedded-processors/armada-80xx/ - Product Brief: - `Armada8020PB-Jan2016.pdf`_ - `Armada8040PB-Jan2016.pdf`_ @@ -272,9 +259,6 @@ Avanta family - 88F6550 - 88F6560 - Homepage: - http://www.marvell.com/broadband/ - Product Brief: `Marvell_Avanta_88F6510_305_060-001_product_brief.pdf`_ @@ -296,9 +280,6 @@ Storage family Armada SP: - 88RC1580 - Product infos: - http://www.marvell.com/storage/armada-sp/ - Core: Sheeva ARMv7 comatible Quad-core PJ4C @@ -319,9 +300,6 @@ Dove family (application processor) Functional Spec: `Armada-510-Functional-Spec.pdf`_ - Homepage: - http://www.marvell.com/application-processors/armada-500/ - Core: ARMv7 compatible @@ -411,7 +389,6 @@ MMP/MMP2/MMP3 family (communication processor) - Application processor only - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) - PXA910/PXA920 - - Homepage : http://www.marvell.com/communication-processors/pxa910/ - Product Brief: `Marvell_PXA910_Platform-001_PB_final.pdf`_ - Application processor with Communication processor - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) -- 2.29.2
[PATCH 0/5] docs: arm: Improvements to Marvell SoC documentation
Hi, please consider applying the patches chained to this message. The objective is to deal with the a large amount of dead links to material that often comes handy in marvel.rst; and improve some details along the way. Thank you Lubo
[PATCH 5/5] docs: arm: marvell: rename marvel.rst to marvell.rst
This company is not the superheroes you're looking for.
Signed-off-by: Lubomir Rintel
---
Documentation/arm/{marvel.rst => marvell.rst} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/arm/{marvel.rst => marvell.rst} (100%)
diff --git a/Documentation/arm/marvel.rst b/Documentation/arm/marvell.rst
similarity index 100%
rename from Documentation/arm/marvel.rst
rename to Documentation/arm/marvell.rst
--
2.29.2
Re: [PATCH 1/4] drivers: phy: add support for Armada CP110 UTMI PHY
On Fri, Jan 29, 2021 at 10:07:13AM +, Russell King - ARM Linux admin wrote: > On Fri, Jan 29, 2021 at 10:28:49AM +0100, Lubomir Rintel wrote: > > > + /* > > > + * Setup PLL. 40MHz clock used to be the default, being 25MHz now. > > > + * See the functional specification for details. > > > > I tried to, couldn't find it. Perhaps you could elaborate more here, or > > include a link in the header. > > Marvell documents are generally not publically available. This is the > case here. In that case the "elaborate more" part applies, otherwise the comment remains rather meaningless. Perhaps it wouldn't be too difficult to clarify things with an extra sentence or two without revealing any secrets. > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! Take care Lubo
[PATCH v7 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Himax HX8837 is used to drive the LCD panel on OLPC platforms.
It controls the panel backlight and is able to refresh it when the LCD
controller (and the rest of the plaform) is powered off.
It also converts regular RGB color data from the LCDC so that it looks
reasonable on the OLPC LCD panel with a monochromatic layer on top of a
layer that can either reflect light (b/w sunlight readable mode) or light
pattern of red, green and blue pixels.
At this point, the driver is rather basic. The self-refresh mode is not
supported. There's no way of independently controlling the color swizzling,
antialiasing or b/w conversion, but it probably isn't too useful either.
There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
DRM, so this driver doesn't replace the other one yet.
Signed-off-by: Lubomir Rintel
---
Changes since v6:
(All also based on feedback from Sam Ravnborg)
- Drop selecting BACKLIGHT_LCD_SUPPORT
- Don't include drm/drm_print.h anymore
- Fix or clarify a couple of error messages
- Remove printing of info banner at end of probe()
Changes since v5:
(All based on feedback from Sam Ravnborg)
- Fix indentation in Kconfig
- Sort #includes
- Use a constant for max brightness instead of a literal
- Remove struct drm_panel from priv data
- Use dev_err() instead of DRM_ERROR
- Replace direct use of backlight props.brightness with
backlight_get_brightness()
- Document sentinels with { /* sentinel */ }
- Remove unsetting of panel->backlight
Changes since v3:
- Added this patch, in place of a driver derived from
drivers/staging/olpc_dcon. Compared to the previous one this
implements the bare minimum, without the fancy stuff such as
self-refresh that need more work/thinking.
drivers/gpu/drm/bridge/Kconfig| 12 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/himax-hx8837.c | 328 ++
3 files changed, 341 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3c..9d753f55bcc05 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,18 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_HIMAX_HX8837
+ tristate "HiMax HX8837 OLPC Display Controller"
+ depends on OF
+ depends on OLPC || ARCH_MMP || COMPILE_TEST
+ select DRM_KMS_HELPER
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ Enable support for HiMax HX8837 Display Controller as found in the
+ OLPC XO laptops.
+
+ If your laptop doesn't have green ears, say "N"
+
config DRM_LONTIUM_LT9611
tristate "Lontium LT9611 DSI/HDMI bridge"
select SND_SOC_HDMI_CODEC if SND_SOC
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d6..1e27939d69d09 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
b/drivers/gpu/drm/bridge/himax-hx8837.c
new file mode 100644
index 0..b97b71ba3f32e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/himax-hx8837.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HiMax HX8837 Display Controller Driver
+ *
+ * Datasheet: http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define bridge_to_hx8837_priv(x) \
+ container_of(x, struct hx8837_priv, bridge)
+
+/* DCON registers */
+enum {
+ DCON_REG_ID = 0x00,
+ DCON_REG_MODE = 0x01,
+ DCON_REG_HRES = 0x02,
+ DCON_REG_HTOTAL = 0x03,
+ DCON_REG_HSYNC_WIDTH= 0x04,
+ DCON_REG_VRES = 0x05,
+ DCON_REG_VTOTAL = 0x06,
+ DCON_REG_VSYNC_WIDTH= 0x07,
+ DCON_REG_TIMEOUT= 0x08,
+ DCON_REG_SCAN_INT = 0x09,
+ DCON_REG_BRIGHT = 0x0a,
+ DCON_REG_MEM_OPT_A = 0x41,
+ DCON_REG_MEM_OPT_B = 0x42,
+};
+
+/* DCON_REG_MODE */
+enum {
+ MODE_PASSTHRU = BIT(0),
+ MODE_SLEEP = BIT(1),
+ MODE_SLEEP_AUTO = BIT(2),
+ MODE_BL_ENABLE = BIT(3),
+ MODE_BLANK = BIT(4),
+
[PATCH v7 1/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
Himax HX8837 is a secondary display controller used to drive the panel
on OLPC platforms.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v6:
(All based on feedback from Laurent Pinchart)
- Add power supplies
- Make load/stat-gpios optional
- Fix whitespace errors
- Use decimal constants instead of hex in example where appropriate
- Terminate the bindings with "..." end-of-document marker
Changes since v4:
- Rob's Reviewed-by
Changes since v3:
- Moved to bindings/display/
- Added the ports
- Converted to YAML
- Removed Pavel's Ack, because the changes are substantial
Changes since v2:
- s/betweend/between/
Changes since v1:
- s/load-gpio/load-gpios/
- Use interrupt bindings instead of gpio for the IRQ
.../bindings/display/bridge/himax,hx8837.yaml | 108 ++
1 file changed, 108 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
new file mode 100644
index 0..e9e21a3447088
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2018,2019,2020,2021 Lubomir Rintel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/himax,hx8837.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HX8837 Display Controller Device Tree Bindings
+
+maintainers:
+ - Lubomir Rintel
+
+properties:
+ compatible:
+const: himax,hx8837
+
+ reg:
+const: 0xd
+
+ load-gpios:
+maxItems: 1
+description: GPIO specifier of DCON_LOAD pin (active high)
+
+ stat-gpios:
+minItems: 2
+description: GPIO specifier of DCON_STAT0 and DCON_STAT1 pins (active high)
+
+ interrupts:
+maxItems: 1
+description: Interrupt specifier of DCON_IRQ pin (edge falling)
+
+ vddp18-supply:
+description: Regulator for 1.8V display interface I/O power.
+
+ vddm25-supply:
+description: Regulator for 2.5V SDRAM I/O power.
+
+ vdd33-supply:
+description: Regulator for 3.3V digital I/O power.
+
+ vddk18-supply:
+description: Regulator for 1.8V internal core power.
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for RGB input.
+
+ port@1:
+type: object
+description: |
+ Video port connected to the panel.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lcd-controller@d {
+compatible = "himax,hx8837";
+reg = <0x0d>;
+stat-gpios = < 100 GPIO_ACTIVE_HIGH>,
+ < 101 GPIO_ACTIVE_HIGH>;
+load-gpios = < 142 GPIO_ACTIVE_HIGH>;
+interrupts = < 124 IRQ_TYPE_EDGE_FALLING>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dcon_rgb_in: endpoint {
+remote-endpoint = <_rgb_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+dcon_gettl_out: endpoint {
+remote-endpoint = <_dettl_in>;
+};
+};
+};
+};
+};
+
+...
--
2.29.2
[PATCH v7 0/2] Add a Himax HX8837 display controller driver
Hi, please take a look at the patches chained to this messages and consider applying them. They add support for the controller that drives the panel on the OLPC XO laptops. Compared to v7, points risen in review by Laurent Pinchart have been addressed. Details in change log of patch 1/2. Tested on an OLPC XO-1.75 laptop. Thank you Lubo
[PATCH] media: marvell-ccic: power up the device on mclk enable
Writing to REG_CLKCTRL with the power off causes a hang. Enable the device first. Cc: sta...@vger.kernel.org # 5.10+ Signed-off-by: Lubomir Rintel --- drivers/media/platform/marvell-ccic/mcam-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c b/drivers/media/platform/marvell-ccic/mcam-core.c index c012fd2e1d291..34266fba824f2 100644 --- a/drivers/media/platform/marvell-ccic/mcam-core.c +++ b/drivers/media/platform/marvell-ccic/mcam-core.c @@ -931,6 +931,7 @@ static int mclk_enable(struct clk_hw *hw) mclk_div = 2; } + pm_runtime_get_sync(cam->dev); clk_enable(cam->clk[0]); mcam_reg_write(cam, REG_CLKCTRL, (mclk_src << 29) | mclk_div); mcam_ctlr_power_up(cam); @@ -944,6 +945,7 @@ static void mclk_disable(struct clk_hw *hw) mcam_ctlr_power_down(cam); clk_disable(cam->clk[0]); + pm_runtime_put(cam->dev); } static unsigned long mclk_recalc_rate(struct clk_hw *hw, -- 2.29.2
[PATCH 3/3] Platform: OLPC: Specify the enable time
Determined empirically.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 3c852d573e9b4..72dbbea0005c5 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -393,11 +393,12 @@ static struct regulator_ops dcon_regulator_ops = {
};
static const struct regulator_desc dcon_desc = {
- .name = "dcon",
- .id = 0,
- .ops= _regulator_ops,
- .type = REGULATOR_VOLTAGE,
- .owner = THIS_MODULE,
+ .name = "dcon",
+ .id = 0,
+ .ops= _regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .enable_time= 25000,
};
static int olpc_ec_probe(struct platform_device *pdev)
--
2.29.2
[PATCH 1/3] Platform: OLPC: Fix probe error handling
Reset ec_priv if probe ends unsuccessfully.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index f64b82824db28..2db7113383fdc 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -426,11 +426,8 @@ static int olpc_ec_probe(struct platform_device *pdev)
/* get the EC revision */
err = olpc_ec_cmd(EC_FIRMWARE_REV, NULL, 0, >version, 1);
- if (err) {
- ec_priv = NULL;
- kfree(ec);
- return err;
- }
+ if (err)
+ goto error;
config.dev = pdev->dev.parent;
config.driver_data = ec;
@@ -440,12 +437,16 @@ static int olpc_ec_probe(struct platform_device *pdev)
if (IS_ERR(ec->dcon_rdev)) {
dev_err(>dev, "failed to register DCON regulator\n");
err = PTR_ERR(ec->dcon_rdev);
- kfree(ec);
- return err;
+ goto error;
}
ec->dbgfs_dir = olpc_ec_setup_debugfs();
+ return 0;
+
+error:
+ ec_priv = NULL;
+ kfree(ec);
return err;
}
--
2.29.2
[PATCH 0/3] Platform: OLPC: A couple of fixes
Hi, chained to this message is a couple of fixes related to OLPC EC platform code. Please take a look and consider applying to platform-drivers-x86. Thank you Lubo
[PATCH 2/3] Platform: OLPC: Remove dcon_rdev from olpc_ec_priv
It is not needed. Use a local variable instead.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 2db7113383fdc..3c852d573e9b4 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -37,7 +37,6 @@ struct olpc_ec_priv {
struct mutex cmd_lock;
/* DCON regulator */
- struct regulator_dev *dcon_rdev;
bool dcon_enabled;
/* Pending EC commands */
@@ -405,6 +404,7 @@ static int olpc_ec_probe(struct platform_device *pdev)
{
struct olpc_ec_priv *ec;
struct regulator_config config = { };
+ struct regulator_dev *regulator;
int err;
if (!ec_driver)
@@ -432,11 +432,10 @@ static int olpc_ec_probe(struct platform_device *pdev)
config.dev = pdev->dev.parent;
config.driver_data = ec;
ec->dcon_enabled = true;
- ec->dcon_rdev = devm_regulator_register(>dev, _desc,
- );
- if (IS_ERR(ec->dcon_rdev)) {
+ regulator = devm_regulator_register(>dev, _desc, );
+ if (IS_ERR(regulator)) {
dev_err(>dev, "failed to register DCON regulator\n");
- err = PTR_ERR(ec->dcon_rdev);
+ err = PTR_ERR(regulator);
goto error;
}
--
2.29.2
[PATCH 2/3] dmaengine: mmp_pdma: Allow building as a module
There is no reason the Marvell MMP peripheral DMA driver would have to be built-in. Signed-off-by: Lubomir Rintel --- drivers/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index d242c76326217..04effa065527b 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -378,7 +378,7 @@ config MILBEAUT_XDMAC XDMAC device. config MMP_PDMA - bool "MMP PDMA support" + tristate "MMP PDMA support" depends on ARCH_MMP || ARCH_PXA || COMPILE_TEST select DMA_ENGINE help -- 2.29.2
[PATCH 1/3] dmaengine: mmp_pdma: Remove mmp_pdma_filter_fn()
It's not used anywhere -- drop it.
Signed-off-by: Lubomir Rintel
---
drivers/dma/mmp_pdma.c | 14 --
include/linux/dma/mmp-pdma.h | 16
2 files changed, 30 deletions(-)
delete mode 100644 include/linux/dma/mmp-pdma.h
diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index b84303be8edf5..89f1814ff27a0 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include "dmaengine.h"
@@ -1148,19 +1147,6 @@ static struct platform_driver mmp_pdma_driver = {
.remove = mmp_pdma_remove,
};
-bool mmp_pdma_filter_fn(struct dma_chan *chan, void *param)
-{
- struct mmp_pdma_chan *c = to_mmp_pdma_chan(chan);
-
- if (chan->device->dev->driver != _pdma_driver.driver)
- return false;
-
- c->drcmr = *(unsigned int *)param;
-
- return true;
-}
-EXPORT_SYMBOL_GPL(mmp_pdma_filter_fn);
-
module_platform_driver(mmp_pdma_driver);
MODULE_DESCRIPTION("MARVELL MMP Peripheral DMA Driver");
diff --git a/include/linux/dma/mmp-pdma.h b/include/linux/dma/mmp-pdma.h
deleted file mode 100644
index 25cab62a28c45..0
--- a/include/linux/dma/mmp-pdma.h
+++ /dev/null
@@ -1,16 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _MMP_PDMA_H_
-#define _MMP_PDMA_H_
-
-struct dma_chan;
-
-#ifdef CONFIG_MMP_PDMA
-bool mmp_pdma_filter_fn(struct dma_chan *chan, void *param);
-#else
-static inline bool mmp_pdma_filter_fn(struct dma_chan *chan, void *param)
-{
- return false;
-}
-#endif
-
-#endif /* _MMP_PDMA_H_ */
--
2.29.2
[PATCH 0/3] dmaengine: Allow building MMP DMA drivers as modules
Hi, please consider attaching the patches chained to this message. The last two are straighforward Kconfig changes that allow building mmp_tdma and mmp_pdma as modules so that distros that will choose to enable the drivers will not add bloat to their kernels for other platforms. The first one gets rid of a symbol that would be exported by mmp_pdma, because it is entirely unnecessary. Thanks, Lubo
[PATCH 3/3] dmaengine: mmp_tdma: Allow building as a module
There is no reason the Marvell MMP two-channel audio DMA driver would have to be built-in. Signed-off-by: Lubomir Rintel --- drivers/dma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 04effa065527b..978b2f526c5df 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -385,7 +385,7 @@ config MMP_PDMA Support the MMP PDMA engine for PXA and MMP platform. config MMP_TDMA - bool "MMP Two-Channel DMA support" + tristate "MMP Two-Channel DMA support" depends on ARCH_MMP || COMPILE_TEST select DMA_ENGINE select GENERIC_ALLOCATOR -- 2.29.2
ARM: dts: mmp devicetree updates
Hi, chained to this message is a handful of patches related to MMP device trees and bindings. Please take a look and consider queueing them for for 5.12. Thank you Lubo
[PATCH 01/12] dt-bindings: gpio: mrvl-gpio: Fix the gpio-ranges property
The property specifies a list of GPIO-capable pins. Don't limit it to a single element as there's presumably more than one GPIO pin. Signed-off-by: Lubomir Rintel --- Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml index 4db3b8a3332c2..9cf6137dd5241 100644 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.yaml @@ -82,8 +82,7 @@ properties: '#gpio-cells': const: 2 - gpio-ranges: -maxItems: 1 + gpio-ranges: true interrupts: true -- 2.29.2
[PATCH 02/12] media: dt-bindings: marvell,mmp2-ccic: Allow power-domains property
On MMP3 the camera interface is on a separate power island. This
property tells the driver to enable it when appropriate.
Signed-off-by: Lubomir Rintel
---
.../devicetree/bindings/media/marvell,mmp2-ccic.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
index 49bff738aca54..52eab686a1774 100644
--- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
+++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml
@@ -23,6 +23,9 @@ properties:
interrupts:
maxItems: 1
+ power-domains:
+maxItems: 1
+
port:
type: object
additionalProperties: false
@@ -75,6 +78,7 @@ additionalProperties: false
examples:
- |
#include
+#include
camera@d420a000 {
compatible = "marvell,mmp2-ccic";
@@ -84,6 +88,7 @@ examples:
clock-names = "axi";
#clock-cells = <0>;
clock-output-names = "mclk";
+ power-domains = <_clocks MMP3_POWER_DOMAIN_CAMERA>;
port {
camera0_0: endpoint {
--
2.29.2
[PATCH 03/12] ARM: dts: mmp2-olpc-xo-1-75: Fix memory node name
It contains a reg property. Add its base to the node name.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
index 342304f5653af..e16171ddd93ec 100644
--- a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
+++ b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
@@ -32,7 +32,7 @@ framebuffer@1fc0 {
};
};
- memory {
+ memory@0 {
linux,usable-memory = <0x0 0x1f80>;
available = <0xcf000 0x1ef31000 0x1000 0xbf000>;
reg = <0x0 0x2000>;
--
2.29.2
[PATCH 04/12] ARM: dts: mmp2-olpc-xo-1-75: Drop linux,usable-memory from /memory
Drop the linux,usable-memory properties; the schema is unhappy about
them:
mmp2-olpc-xo-1-75.dt.yaml: /: memory: False schema does not allow
{'linux,usable-memory': [[0, 528482304]],
'available': [[847872, 519245824, 4096, 782336]],
'reg': [[0, 536870912]], 'device_type': ['memory']}
They've been cargo-culted from Open Firmware and I don't know what
purpose they serve. Perhaps they are meant to provide the OFW runtime.
In that case it's still okay to drop them from here; OFW is welcome to add
it upon boot.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
index e16171ddd93ec..0f8b5ad48deed 100644
--- a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
+++ b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
@@ -33,7 +33,6 @@ framebuffer@1fc0 {
};
memory@0 {
- linux,usable-memory = <0x0 0x1f80>;
available = <0xcf000 0x1ef31000 0x1000 0xbf000>;
reg = <0x0 0x2000>;
device_type = "memory";
--
2.29.2
[PATCH 10/12] ARM: dts: mmp3-dell-ariel: Add the power button node
This adds support for the power button attached to the Embedded Controller
on a Dell Wyse 3020 "Ariel" board.
However, while the EC itself is controlled via I2C, the input capability
for the power button acts as a separate device attached to the SPI, hence
it has a separate device node.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp3-dell-ariel.dts | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp3-dell-ariel.dts
b/arch/arm/boot/dts/mmp3-dell-ariel.dts
index 565cd0fadf3d3..c4a6bd876d849 100644
--- a/arch/arm/boot/dts/mmp3-dell-ariel.dts
+++ b/arch/arm/boot/dts/mmp3-dell-ariel.dts
@@ -119,8 +119,16 @@ firmware-flash@0 {
};
{
- cs-gpios = < 56 GPIO_ACTIVE_LOW>;
status = "okay";
+ cs-gpios = < 56 GPIO_ACTIVE_LOW>;
+
+ power-button@0 {
+ reg = <0>;
+ interrupt-parent = <>;
+ interrupts = <60 IRQ_TYPE_EDGE_RISING>;
+ compatible = "dell,wyse-ariel-ec-input", "ene,kb3930-input";
+ spi-max-frequency = <3300>;
+ };
};
_2d {
--
2.29.2
[PATCH 05/12] ARM: dts: mmp3-dell-ariel: Drop linux,usable-memory from /memory
Drop the linux,usable-memory properties; the schema is unhappy about
them.
They've been cargo-culted from Open Firmware and I don't know what
purpose they serve. Perhaps they are meant to provide the OFW runtime.
In that case it's still okay to drop them from here; OFW is welcome to add
it upon boot.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp3-dell-ariel.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp3-dell-ariel.dts
b/arch/arm/boot/dts/mmp3-dell-ariel.dts
index fe3b1cd695eeb..53714cb0d171e 100644
--- a/arch/arm/boot/dts/mmp3-dell-ariel.dts
+++ b/arch/arm/boot/dts/mmp3-dell-ariel.dts
@@ -26,7 +26,6 @@ chosen {
};
memory@0 {
- linux,usable-memory = <0x0 0x7f60>;
available = <0x7f70 0x7ff0 0x 0x7f60>;
reg = <0x0 0x8000>;
device_type = "memory";
--
2.29.2
[PATCH 12/12] ARM: dts: mmp3: Fix the CCIC interrupts
A copy & paste oversight from MMP2; camera interrupts are handled
via a multiplexer on MMP3.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp3.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mmp3.dtsi b/arch/arm/boot/dts/mmp3.dtsi
index 9f2b059f0900b..a4fb9203ec1fb 100644
--- a/arch/arm/boot/dts/mmp3.dtsi
+++ b/arch/arm/boot/dts/mmp3.dtsi
@@ -293,7 +293,8 @@ mmc5: mmc@d4217000 {
camera0: camera@d420a000 {
compatible = "marvell,mmp2-ccic";
reg = <0xd420a000 0x800>;
- interrupts = ;
+ interrupts = <1>;
+ interrupt-parent = <_mux>;
clocks = <_clocks MMP2_CLK_CCIC0>;
clock-names = "axi";
power-domains = <_clocks
MMP3_POWER_DOMAIN_CAMERA>;
@@ -305,7 +306,8 @@ camera0: camera@d420a000 {
camera1: camera@d420a800 {
compatible = "marvell,mmp2-ccic";
reg = <0xd420a800 0x800>;
- interrupts = ;
+ interrupts = <2>;
+ interrupt-parent = <_mux>;
clocks = <_clocks MMP2_CLK_CCIC1>;
clock-names = "axi";
power-domains = <_clocks
MMP3_POWER_DOMAIN_CAMERA>;
--
2.29.2
[PATCH 11/12] ARM: dts: mmp3-dell-ariel: Replace SSP2 with spi-gpio
The firmware leaves the pins in GPIO mode. Until we have a proper pinmux
driver hooked on we just need to bitbang SPI. No big deal, this is just
used for the power button and performance is not important.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp3-dell-ariel.dts | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp3-dell-ariel.dts
b/arch/arm/boot/dts/mmp3-dell-ariel.dts
index c4a6bd876d849..fe6df364a9eb6 100644
--- a/arch/arm/boot/dts/mmp3-dell-ariel.dts
+++ b/arch/arm/boot/dts/mmp3-dell-ariel.dts
@@ -30,6 +30,17 @@ memory@0 {
reg = <0x0 0x8000>;
device_type = "memory";
};
+
+ ec_input_spi: spi {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ num-chipselects = <0>;
+ sck-gpios = < 55 GPIO_ACTIVE_HIGH>;
+ miso-gpios = < 57 GPIO_ACTIVE_HIGH>;
+ mosi-gpios = < 58 GPIO_ACTIVE_HIGH>;
+ };
};
{
@@ -118,7 +129,7 @@ firmware-flash@0 {
};
};
- {
+_input_spi {
status = "okay";
cs-gpios = < 56 GPIO_ACTIVE_LOW>;
--
2.29.2
[PATCH 06/12] ARM: dts: mmp3: Extend the MPMU reg range
The ACGR register is at the offset of 0x1024, beyond the 4k originally
assigned to the MPMU range.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp3.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp3.dtsi b/arch/arm/boot/dts/mmp3.dtsi
index 4ae630d37d094..9f2b059f0900b 100644
--- a/arch/arm/boot/dts/mmp3.dtsi
+++ b/arch/arm/boot/dts/mmp3.dtsi
@@ -567,7 +567,7 @@ l2: cache-controller@d002 {
soc_clocks: clocks@d405 {
compatible = "marvell,mmp3-clock";
- reg = <0xd405 0x1000>,
+ reg = <0xd405 0x2000>,
<0xd4282800 0x400>,
<0xd4015000 0x1000>;
reg-names = "mpmu", "apmu", "apbc";
--
2.29.2
[PATCH 07/12] ARM: dts: mmp2: Use symbolic names for audio clocks
These are slighly easier to read.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp2.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 445bdcd50b9ed..46984d4c5224f 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -6,6 +6,7 @@
#include
#include
+#include
/ {
#address-cells = <1>;
@@ -243,7 +244,7 @@ sspa0: audio-controller@d42a0c00 {
interrupts = <2>;
clock-names = "audio", "bitclk";
clocks = <_clocks MMP2_CLK_AUDIO>,
-<_clk 1>;
+<_clk MMP2_CLK_AUDIO_SSPA0>;
power-domains = <_clocks
MMP2_POWER_DOMAIN_AUDIO>;
#sound-dai-cells = <0>;
status = "disabled";
@@ -256,7 +257,7 @@ sspa1: audio-controller@d42a0d00 {
interrupts = <3>;
clock-names = "audio", "bitclk";
clocks = <_clocks MMP2_CLK_AUDIO>,
-<_clk 2>;
+<_clk MMP2_CLK_AUDIO_SSPA1>;
power-domains = <_clocks
MMP2_POWER_DOMAIN_AUDIO>;
#sound-dai-cells = <0>;
status = "disabled";
--
2.29.2
[PATCH 08/12] ARM: dts: mmp2-olpc-xo-1-75: Use symbolic names for audio clocks
These are slighly easier to read.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
index 0f8b5ad48deed..55ea87870af3e 100644
--- a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
+++ b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
@@ -2,7 +2,7 @@
/*
* OLPC XO 1.75 Laptop.
*
- * Copyright (C) 2018,2019 Lubomir Rintel
+ * Copyright (C) 2018,2019,2020 Lubomir Rintel
*/
/dts-v1/;
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
model = "OLPC XO-1.75";
@@ -194,7 +195,7 @@ audio-codec@1a {
port {
rt5631_0: endpoint {
mclk-fs = <256>;
- clocks = <_clk 0>;
+ clocks = <_clk MMP2_CLK_AUDIO_SYSCLK>;
remote-endpoint = <_0>;
};
};
--
2.29.2
[PATCH 09/12] ARM: dts: mmp3-dell-ariel: Add the embedded controller
Add the device node for the computer's embedded controller, responsible
for controlling the LEDs and system power.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp3-dell-ariel.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/mmp3-dell-ariel.dts
b/arch/arm/boot/dts/mmp3-dell-ariel.dts
index 53714cb0d171e..565cd0fadf3d3 100644
--- a/arch/arm/boot/dts/mmp3-dell-ariel.dts
+++ b/arch/arm/boot/dts/mmp3-dell-ariel.dts
@@ -95,6 +95,15 @@ {
{
status = "okay";
+
+ embedded-controller@58 {
+ compatible = "dell,wyse-ariel-ec", "ene,kb3930";
+ reg = <0x58>;
+ system-power-controller;
+
+ off-gpios = < 126 GPIO_ACTIVE_HIGH>,
+ < 127 GPIO_ACTIVE_HIGH>;
+ };
};
{
--
2.29.2
Re: [PATCH] input: ariel-pwrbutton.c: Remove unused variable ariel_pwrbutton_id_table[]
On Mon, Jan 04, 2021 at 02:02:13PM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 29, 2020 at 01:15:10PM +0530, Souptick Joarder wrote:
> > On Tue, Dec 22, 2020 at 1:34 AM Souptick Joarder
> > wrote:
> > >
> > > Kernel test robot throws below warning ->
> > >
> > > >> drivers/input/misc/ariel-pwrbutton.c:152:35: warning: unused variable
> > > >> 'ariel_pwrbutton_id_table' [-Wunused-const-variable]
> > >static const struct spi_device_id ariel_pwrbutton_id_table[] = {
> > > ^
> > >1 warning generated.
> > >
> > > Remove unused variable ariel_pwrbutton_id_table[] if no plan to use
> > > it further.
> > >
> > > Reported-by: kernel test robot
> > > Signed-off-by: Souptick Joarder
> >
> > Any comment on this patch ?
>
> Lubomir, would you prefer to remove the table or add it to the driver
> structure as ariel_pwrbutton_driver->id_table?
I believe it can be safely dropped, as the OF match seems to be
sufficient.
Thank you for the patch Souptick.
Reviewed-by: Lubomir Rintel
>
> Thanks.
>
> --
> Dmitry
Re: [PATCH] clk: mmp2: fix build without CONFIG_PM
On Sun, Jan 03, 2021 at 02:54:53PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> pm_clk_suspend()/pm_clk_resume() are defined as NULL pointers rather than
> empty inline stubs without CONFIG_PM:
>
> drivers/clk/mmp/clk-audio.c:402:16: error: called object type 'void *' is not
> a function or function pointer
> pm_clk_suspend(dev);
> drivers/clk/mmp/clk-audio.c:411:15: error: called object type 'void *' is not
> a function or function pointer
> pm_clk_resume(dev);
>
> I tried redefining the helper functions, but that caused additional
> problems. This is the simple solution of replacing the __maybe_unused
> trick with an #ifdef.
>
> Fixes: 725262d29139 ("clk: mmp2: Add audio clock controller driver")
> Signed-off-by: Arnd Bergmann
Thank you.
Acked-By: Lubomir Rintel
> ---
> drivers/clk/mmp/clk-audio.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mmp/clk-audio.c b/drivers/clk/mmp/clk-audio.c
> index eea69d498bd2..7aa7f4a9564f 100644
> --- a/drivers/clk/mmp/clk-audio.c
> +++ b/drivers/clk/mmp/clk-audio.c
> @@ -392,7 +392,8 @@ static int mmp2_audio_clk_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static int __maybe_unused mmp2_audio_clk_suspend(struct device *dev)
> +#ifdef CONFIG_PM
> +static int mmp2_audio_clk_suspend(struct device *dev)
> {
> struct mmp2_audio_clk *priv = dev_get_drvdata(dev);
>
> @@ -404,7 +405,7 @@ static int __maybe_unused mmp2_audio_clk_suspend(struct
> device *dev)
> return 0;
> }
>
> -static int __maybe_unused mmp2_audio_clk_resume(struct device *dev)
> +static int mmp2_audio_clk_resume(struct device *dev)
> {
> struct mmp2_audio_clk *priv = dev_get_drvdata(dev);
>
> @@ -415,6 +416,7 @@ static int __maybe_unused mmp2_audio_clk_resume(struct
> device *dev)
>
> return 0;
> }
> +#endif
>
> static const struct dev_pm_ops mmp2_audio_clk_pm_ops = {
> SET_RUNTIME_PM_OPS(mmp2_audio_clk_suspend, mmp2_audio_clk_resume, NULL)
> --
> 2.29.2
>
[PATCH v4 2/2] Input: add driver for power button on Dell Wyse 3020
This adds support for the power button attached to the Embedded Controller
on a Dell Wyse 3020 "Ariel" board.
The Embedded Controller's SPI interface is actually capable sending and
receiving the PS/2 keyboard and mouse protocol data, which looks like
a good fit for a serio driver. Howerver, I don't know of any machines where
this is actually used.
My board only has a single power button and no way to connect an actual
keyboard or a mouse. Using the atkbd driver with serio would be an overkill
and would be inconvenient for the userspace. Therefore this driver
registers an input device that is only capable of reporting the power
button presses and releases.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
(All by the suggestions of Dmitry Torokhov. Thank you Dmitry!)
- Add more includes
- Make ariel_pwrbutton.msg_counter not a bitfield
- Include an error code in error message when ec_input_read() fails in
the interrupt handler.
- Return from the interrupt handler from a single point.
- Remove a forgotten debug statement.
- s/ret/error/
- Return -EINVAL instead of -ENXIO when the IRQ line is not specified.
- Don't hardcode rising edge trigger, rely on DT instead
- Remove a banner print at the end of probe().
Changes since v1:
- Do away bitfields in order to be endian independent
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/ariel-pwrbutton.c | 169 +++
3 files changed, 181 insertions(+)
create mode 100644 drivers/input/misc/ariel-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 362e8a01980cd..e7bb572e15182 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -73,6 +73,17 @@ config INPUT_AD714X_SPI
To compile this driver as a module, choose M here: the
module will be called ad714x-spi.
+config INPUT_ARIEL_PWRBUTTON
+ tristate "Dell Wyse 3020 Power Button Driver"
+ depends on SPI
+ depends on MACH_MMP3_DT || COMPILE_TEST
+ help
+ Say Y to enable support for reporting power button status on
+ on Dell Wyse 3020 ("Ariel") thin client.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ariel-pwrbutton.
+
config INPUT_ARIZONA_HAPTICS
tristate "Arizona haptics support"
depends on MFD_ARIZONA && SND_SOC
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a48e5f2d859d4..062cea9f181c9 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ADXL34X) += adxl34x.o
obj-$(CONFIG_INPUT_ADXL34X_I2C)+= adxl34x-i2c.o
obj-$(CONFIG_INPUT_ADXL34X_SPI)+= adxl34x-spi.o
obj-$(CONFIG_INPUT_APANEL) += apanel.o
+obj-$(CONFIG_INPUT_ARIEL_PWRBUTTON)+= ariel-pwrbutton.o
obj-$(CONFIG_INPUT_ARIZONA_HAPTICS)+= arizona-haptics.o
obj-$(CONFIG_INPUT_ATI_REMOTE2)+= ati_remote2.o
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
diff --git a/drivers/input/misc/ariel-pwrbutton.c
b/drivers/input/misc/ariel-pwrbutton.c
new file mode 100644
index 0..eda86ab552b9c
--- /dev/null
+++ b/drivers/input/misc/ariel-pwrbutton.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0-or-later
+/*
+ * Dell Wyse 3020 a.k.a. "Ariel" Power Button Driver
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RESP_COUNTER(response) (response.header & 0x3)
+#define RESP_SIZE(response)((response.header >> 2) & 0x3)
+#define RESP_TYPE(response)((response.header >> 4) & 0xf)
+
+struct ec_input_response {
+ u8 reserved;
+ u8 header;
+ u8 data[3];
+} __packed;
+
+struct ariel_pwrbutton {
+ struct spi_device *client;
+ struct input_dev *input;
+ u8 msg_counter;
+};
+
+static int ec_input_read(struct ariel_pwrbutton *priv,
+struct ec_input_response *response)
+{
+ u8 read_request[] = { 0x00, 0x5a, 0xa5, 0x00, 0x00 };
+ struct spi_device *spi = priv->client;
+ struct spi_transfer t = {
+ .tx_buf = read_request,
+ .rx_buf = response,
+ .len = sizeof(read_request),
+ };
+
+ compiletime_assert(sizeof(read_request) == sizeof(*response),
+ "SPI xfer request/response size mismatch");
+
+ return spi_sync_transfer(spi, , 1);
+}
+
+static irqreturn_t ec_input_interrupt(int irq, void *dev_id)
+{
+ struct ariel_pwrbutton *priv = dev_id;
+ struct spi_device *spi = priv->client;
+ struct ec_input_response response;
+ int error;
+ int i;
+
+ error = ec_input_read(priv, );
+ if (error < 0) {
+ dev_err(>
[PATCH v4 1/2] dt-bindings: input: Add Dell Wyse 3020 Power Button binding
Add binding document for the Dell Wyse 3020 a.k.a. "Ariel" Power Button.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v3:
(Based on warnings from Rob's validation bot)
- Specify additionalProperties: false
- Allow using spi-max-frequency property
Changes since v1:
- Collect Rob's R-b
.../bindings/input/ariel-pwrbutton.yaml | 57 +++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
diff --git a/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
new file mode 100644
index 0..b4ad829d73838
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ariel-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dell Wyse 3020 a.k.a. "Ariel" Power Button
+
+maintainers:
+ - Lubomir Rintel
+
+description: |
+ The ENE Embedded Controller on the Ariel board has an interface to the
+ SPI bus that is capable of sending keyboard and mouse data. A single
+ power button is attached to it. This binding describes this
+ configuration.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+items:
+ - const: dell,wyse-ariel-ec-input
+ - const: ene,kb3930-input
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ spi-max-frequency: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+power-button@0 {
+compatible = "dell,wyse-ariel-ec-input", "ene,kb3930-input";
+reg = <0>;
+interrupt-parent = <>;
+interrupts = <60 IRQ_TYPE_EDGE_RISING>;
+spi-max-frequency = <3300>;
+};
+};
--
2.28.0
[PATCH v4 0/2] Add driver for power button on Dell Wyse 3020
please consider applying the patches chained to this message. It's a rather simple driver for a power button on Dell Ariel board along with the Device Tree binding document. Compared to previous version, it fixes a validation warning in the DT bindings. Change logs are present in individual patches. Thank you Lubo
[PATCH RFC 1/4] Platform: OLPC: Specify the enable time for DCON power
It takes some significant time between when we ask the EC to enable the
DCON power and when we can access the DCON registers.
FIXME: Maybe some of the delay is caused on the DCON side once the power
is good. Need to check with a scope I suppose.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index f64b82824db28..faecb73bd8430 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -394,11 +394,12 @@ static struct regulator_ops dcon_regulator_ops = {
};
static const struct regulator_desc dcon_desc = {
- .name = "dcon",
- .id = 0,
- .ops= _regulator_ops,
- .type = REGULATOR_VOLTAGE,
- .owner = THIS_MODULE,
+ .name = "dcon",
+ .id = 0,
+ .ops= _regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .enable_time= 25000,
};
static int olpc_ec_probe(struct platform_device *pdev)
--
2.28.0
[PATCH RFC 4/4] Platform: OLPC: Register regulators for all power lines to DCON
The EC switches three power lines for the display controller:
2.5V for the self-refresh frame SDRAM
3.3V for the digital I/O pins
1.8V for the controller core and also the DETTL display interface
pins.
Note that all lines can be either disabled or enabled together.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 92 +++--
1 file changed, 65 insertions(+), 27 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 72dbbea0005c5..2ab57ffb3d63e 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -5,6 +5,7 @@
* Author: Andres Salomon
*
* Copyright (C) 2011-2012 One Laptop per Child Foundation.
+ * Copyright (C) 2020 Lubomir Rintel
*/
#include
#include
@@ -17,6 +18,7 @@
#include
#include
#include
+#include
struct ec_cmd_desc {
u8 cmd;
@@ -37,7 +39,7 @@ struct olpc_ec_priv {
struct mutex cmd_lock;
/* DCON regulator */
- bool dcon_enabled;
+ unsigned int dcon_enable_count;
/* Pending EC commands */
struct list_head cmd_q;
@@ -352,38 +354,45 @@ static struct dentry *olpc_ec_setup_debugfs(void)
static int olpc_ec_set_dcon_power(struct olpc_ec_priv *ec, bool state)
{
unsigned char ec_byte = state;
- int ret;
- if (ec->dcon_enabled == state)
- return 0;
-
- ret = olpc_ec_cmd(EC_DCON_POWER_MODE, _byte, 1, NULL, 0);
- if (ret)
- return ret;
-
- ec->dcon_enabled = state;
- return 0;
+ return olpc_ec_cmd(EC_DCON_POWER_MODE, _byte, 1, NULL, 0);
}
static int dcon_regulator_enable(struct regulator_dev *rdev)
{
struct olpc_ec_priv *ec = rdev_get_drvdata(rdev);
+ int ret;
- return olpc_ec_set_dcon_power(ec, true);
+ if (ec->dcon_enable_count == 0) {
+ ret = olpc_ec_set_dcon_power(ec, true);
+ if (ret)
+ return ret;
+ }
+
+ ec->dcon_enable_count++;
+ return 0;
}
static int dcon_regulator_disable(struct regulator_dev *rdev)
{
struct olpc_ec_priv *ec = rdev_get_drvdata(rdev);
+ int ret;
- return olpc_ec_set_dcon_power(ec, false);
+ if (ec->dcon_enable_count == 1) {
+ ret = olpc_ec_set_dcon_power(ec, false);
+ if (ret)
+ return ret;
+ }
+
+ ec->dcon_enable_count--;
+ return 0;
}
static int dcon_regulator_is_enabled(struct regulator_dev *rdev)
{
struct olpc_ec_priv *ec = rdev_get_drvdata(rdev);
- return ec->dcon_enabled ? 1 : 0;
+ return ec->dcon_enable_count ? 1 : 0;
}
static struct regulator_ops dcon_regulator_ops = {
@@ -392,13 +401,36 @@ static struct regulator_ops dcon_regulator_ops = {
.is_enabled = dcon_regulator_is_enabled,
};
-static const struct regulator_desc dcon_desc = {
- .name = "dcon",
- .id = 0,
- .ops= _regulator_ops,
- .type = REGULATOR_VOLTAGE,
- .owner = THIS_MODULE,
- .enable_time= 25000,
+static const struct regulator_desc regulators[] = {
+ {
+ .name = "v2_5_dcon",
+ .of_match = of_match_ptr("v2_5_dcon"),
+ .regulators_node = of_match_ptr("regulators"),
+ .n_voltages = 1,
+ .fixed_uV = 250,
+ .ops= _regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ }, {
+ .name = "v3_3_dcon",
+ .of_match = of_match_ptr("v3_3_dcon"),
+ .regulators_node = of_match_ptr("regulators"),
+ .n_voltages = 1,
+ .fixed_uV = 330,
+ .ops= _regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ }, {
+ .name = "v1_8_dcon",
+ .of_match = of_match_ptr("v1_8_dcon"),
+ .regulators_node = of_match_ptr("regulators"),
+ .n_voltages = 1,
+ .fixed_uV = 180,
+ .ops= _regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+ .enable_time= 25000,
+ }
};
static int olpc_ec_probe(struct platform_device *pdev)
@@ -406,6 +438,7 @@ static int olpc_ec_probe(struct platform_device *pdev)
struct olpc_ec_priv *ec;
struct regulator_config config = { };
struct regulator_dev *regulator;
+ int i;
int err;
if (!ec_driver)
@@ -432,12 +465,17 @@ static int olpc
[PATCH RFC 0/4] Platform: OLPC: Register regulators for all power lines to DCON
Hi, I'm wondering if I could ask for help hooking up the OLPC display controller driver to the power regulator framework. The DCON chip uses four different power supplies (3.3V, 2.5V and two 1.8V) and the EC is in charge of switching the regulators. I'm not sure how does this plug into the regulator framework. Is it okay if I make the EC driver expose the regulators and enforce that they all enable at the same time? The patch set below aims to implement something like that: The first three patches are just loosely related to the problem; they just prepare the field for the last patch: [PATCH RFC 1/4] Platform: OLPC: Specify the enable time for DCON power [PATCH RFC 2/4] Platform: OLPC: Fix handling of regulator registration [PATCH RFC 3/4] Platform: OLPC: Remove regulator_dev from the priv struct This exposes three regulators all controlling the same EC power interface: [PATCH RFC 4/4] Platform: OLPC: Register regulators for all power lines Thank you Lubo
[PATCH RFC 2/4] Platform: OLPC: Fix handling of regulator registration error
We wouldn't reset ec_priv previously. Let's handle handle the errors in
a single spot to fix this.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index faecb73bd8430..2ad638583cc58 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -427,11 +427,8 @@ static int olpc_ec_probe(struct platform_device *pdev)
/* get the EC revision */
err = olpc_ec_cmd(EC_FIRMWARE_REV, NULL, 0, >version, 1);
- if (err) {
- ec_priv = NULL;
- kfree(ec);
- return err;
- }
+ if (err)
+ goto error;
config.dev = pdev->dev.parent;
config.driver_data = ec;
@@ -441,12 +438,16 @@ static int olpc_ec_probe(struct platform_device *pdev)
if (IS_ERR(ec->dcon_rdev)) {
dev_err(>dev, "failed to register DCON regulator\n");
err = PTR_ERR(ec->dcon_rdev);
- kfree(ec);
- return err;
+ goto error;
}
ec->dbgfs_dir = olpc_ec_setup_debugfs();
+ return 0;
+
+error:
+ ec_priv = NULL;
+ kfree(ec);
return err;
}
--
2.28.0
[PATCH RFC 3/4] Platform: OLPC: Remove regulator_dev from the priv struct
We don't need it as it's device-managed. A local variable will do.
Signed-off-by: Lubomir Rintel
---
drivers/platform/olpc/olpc-ec.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/olpc/olpc-ec.c b/drivers/platform/olpc/olpc-ec.c
index 2ad638583cc58..72dbbea0005c5 100644
--- a/drivers/platform/olpc/olpc-ec.c
+++ b/drivers/platform/olpc/olpc-ec.c
@@ -37,7 +37,6 @@ struct olpc_ec_priv {
struct mutex cmd_lock;
/* DCON regulator */
- struct regulator_dev *dcon_rdev;
bool dcon_enabled;
/* Pending EC commands */
@@ -406,6 +405,7 @@ static int olpc_ec_probe(struct platform_device *pdev)
{
struct olpc_ec_priv *ec;
struct regulator_config config = { };
+ struct regulator_dev *regulator;
int err;
if (!ec_driver)
@@ -433,11 +433,10 @@ static int olpc_ec_probe(struct platform_device *pdev)
config.dev = pdev->dev.parent;
config.driver_data = ec;
ec->dcon_enabled = true;
- ec->dcon_rdev = devm_regulator_register(>dev, _desc,
- );
- if (IS_ERR(ec->dcon_rdev)) {
+ regulator = devm_regulator_register(>dev, _desc, );
+ if (IS_ERR(regulator)) {
dev_err(>dev, "failed to register DCON regulator\n");
- err = PTR_ERR(ec->dcon_rdev);
+ err = PTR_ERR(regulator);
goto error;
}
--
2.28.0
[PATCH v3 2/2] Input: add driver for power button on Dell Wyse 3020
This adds support for the power button attached to the Embedded Controller
on a Dell Wyse 3020 "Ariel" board.
The Embedded Controller's SPI interface is actually capable sending and
receiving the PS/2 keyboard and mouse protocol data, which looks like
a good fit for a serio driver. Howerver, I don't know of any machines where
this is actually used.
My board only has a single power button and no way to connect an actual
keyboard or a mouse. Using the atkbd driver with serio would be an overkill
and would be inconvenient for the userspace. Therefore this driver
registers an input device that is only capable of reporting the power
button presses and releases.
Signed-off-by: Lubomir Rintel
---
Changes since v2:
(All by the suggestions of Dmitry Torokhov. Thank you Dmitry!)
- Add more includes
- Make ariel_pwrbutton.msg_counter not a bitfield
- Include an error code in error message when ec_input_read() fails in
the interrupt handler.
- Return from the interrupt handler from a single point.
- Remove a forgotten debug statement.
- s/ret/error/
- Return -EINVAL instead of -ENXIO when the IRQ line is not specified.
- Don't hardcode rising edge trigger, rely on DT instead
- Remove a banner print at the end of probe().
Changes since v1:
- Do away bitfields in order to be endian independent
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/ariel-pwrbutton.c | 169 +++
3 files changed, 181 insertions(+)
create mode 100644 drivers/input/misc/ariel-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 362e8a01980cd..e7bb572e15182 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -73,6 +73,17 @@ config INPUT_AD714X_SPI
To compile this driver as a module, choose M here: the
module will be called ad714x-spi.
+config INPUT_ARIEL_PWRBUTTON
+ tristate "Dell Wyse 3020 Power Button Driver"
+ depends on SPI
+ depends on MACH_MMP3_DT || COMPILE_TEST
+ help
+ Say Y to enable support for reporting power button status on
+ on Dell Wyse 3020 ("Ariel") thin client.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ariel-pwrbutton.
+
config INPUT_ARIZONA_HAPTICS
tristate "Arizona haptics support"
depends on MFD_ARIZONA && SND_SOC
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a48e5f2d859d4..062cea9f181c9 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ADXL34X) += adxl34x.o
obj-$(CONFIG_INPUT_ADXL34X_I2C)+= adxl34x-i2c.o
obj-$(CONFIG_INPUT_ADXL34X_SPI)+= adxl34x-spi.o
obj-$(CONFIG_INPUT_APANEL) += apanel.o
+obj-$(CONFIG_INPUT_ARIEL_PWRBUTTON)+= ariel-pwrbutton.o
obj-$(CONFIG_INPUT_ARIZONA_HAPTICS)+= arizona-haptics.o
obj-$(CONFIG_INPUT_ATI_REMOTE2)+= ati_remote2.o
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
diff --git a/drivers/input/misc/ariel-pwrbutton.c
b/drivers/input/misc/ariel-pwrbutton.c
new file mode 100644
index 0..eda86ab552b9c
--- /dev/null
+++ b/drivers/input/misc/ariel-pwrbutton.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0-or-later
+/*
+ * Dell Wyse 3020 a.k.a. "Ariel" Power Button Driver
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RESP_COUNTER(response) (response.header & 0x3)
+#define RESP_SIZE(response)((response.header >> 2) & 0x3)
+#define RESP_TYPE(response)((response.header >> 4) & 0xf)
+
+struct ec_input_response {
+ u8 reserved;
+ u8 header;
+ u8 data[3];
+} __packed;
+
+struct ariel_pwrbutton {
+ struct spi_device *client;
+ struct input_dev *input;
+ u8 msg_counter;
+};
+
+static int ec_input_read(struct ariel_pwrbutton *priv,
+struct ec_input_response *response)
+{
+ u8 read_request[] = { 0x00, 0x5a, 0xa5, 0x00, 0x00 };
+ struct spi_device *spi = priv->client;
+ struct spi_transfer t = {
+ .tx_buf = read_request,
+ .rx_buf = response,
+ .len = sizeof(read_request),
+ };
+
+ compiletime_assert(sizeof(read_request) == sizeof(*response),
+ "SPI xfer request/response size mismatch");
+
+ return spi_sync_transfer(spi, , 1);
+}
+
+static irqreturn_t ec_input_interrupt(int irq, void *dev_id)
+{
+ struct ariel_pwrbutton *priv = dev_id;
+ struct spi_device *spi = priv->client;
+ struct ec_input_response response;
+ int error;
+ int i;
+
+ error = ec_input_read(priv, );
+ if (error < 0) {
+ dev_err(>
[PATCH v3 1/2] dt-bindings: input: Add Dell Wyse 3020 Power Button binding
Add binding document for the Dell Wyse 3020 a.k.a. "Ariel" Power Button.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v1:
- Collect Rob's R-b
.../bindings/input/ariel-pwrbutton.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
diff --git a/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
new file mode 100644
index 0..e022d36c48d23
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ariel-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dell Wyse 3020 a.k.a. "Ariel" Power Button
+
+maintainers:
+ - Lubomir Rintel
+
+description: |
+ The ENE Embedded Controller on the Ariel board has an interface to the
+ SPI bus that is capable of sending keyboard and mouse data. A single
+ power button is attached to it. This binding describes this
+ configuration.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+items:
+ - const: dell,wyse-ariel-ec-input
+ - const: ene,kb3930-input
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+power-button@0 {
+compatible = "dell,wyse-ariel-ec-input", "ene,kb3930-input";
+reg = <0>;
+interrupt-parent = <>;
+interrupts = <60 IRQ_TYPE_EDGE_RISING>;
+spi-max-frequency = <3300>;
+};
+};
--
2.28.0
[PATCH v3 0/2] Add driver for power button on Dell Wyse 3020
Hi, please consider applying the patches chained to this message. It's a rather simple driver for a power button on Dell Ariel board along with the Device Tree binding document. Compared to previous version, issues pointed out in the review by Dmitry Torokhov have been addressed. Change logs are present in individual patches. Thank you Lubo
[PATCH v2 2/2] Input: add driver for power button on Dell Wyse 3020
This adds support for the power button attached to the Embedded Controller
on a Dell Wyse 3020 "Ariel" board.
The Embedded Controller's SPI interface is actually capable sending and
receiving the PS/2 keyboard and mouse protocol data, which looks like
a good fit for a serio driver. Howerver, I don't know of any machines where
this is actually used.
My board only has a single power button and no way to connect an actual
keyboard or a mouse. Using the atkbd driver with serio would be an overkill
and would be inconvenient for the userspace. Therefore this driver
registers an input device that is only capable of reporting the power
button presses and releases.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Do away bitfields in order to be endian independent
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/ariel-pwrbutton.c | 165 +++
3 files changed, 177 insertions(+)
create mode 100644 drivers/input/misc/ariel-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 362e8a01980cd..e7bb572e15182 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -73,6 +73,17 @@ config INPUT_AD714X_SPI
To compile this driver as a module, choose M here: the
module will be called ad714x-spi.
+config INPUT_ARIEL_PWRBUTTON
+ tristate "Dell Wyse 3020 Power Button Driver"
+ depends on SPI
+ depends on MACH_MMP3_DT || COMPILE_TEST
+ help
+ Say Y to enable support for reporting power button status on
+ on Dell Wyse 3020 ("Ariel") thin client.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ariel-pwrbutton.
+
config INPUT_ARIZONA_HAPTICS
tristate "Arizona haptics support"
depends on MFD_ARIZONA && SND_SOC
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index a48e5f2d859d4..062cea9f181c9 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_INPUT_ADXL34X) += adxl34x.o
obj-$(CONFIG_INPUT_ADXL34X_I2C)+= adxl34x-i2c.o
obj-$(CONFIG_INPUT_ADXL34X_SPI)+= adxl34x-spi.o
obj-$(CONFIG_INPUT_APANEL) += apanel.o
+obj-$(CONFIG_INPUT_ARIEL_PWRBUTTON)+= ariel-pwrbutton.o
obj-$(CONFIG_INPUT_ARIZONA_HAPTICS)+= arizona-haptics.o
obj-$(CONFIG_INPUT_ATI_REMOTE2)+= ati_remote2.o
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
diff --git a/drivers/input/misc/ariel-pwrbutton.c
b/drivers/input/misc/ariel-pwrbutton.c
new file mode 100644
index 0..502bc6a65f657
--- /dev/null
+++ b/drivers/input/misc/ariel-pwrbutton.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: BSD-2-Clause OR GPL-2.0-or-later
+/*
+ * Dell Wyse 3020 a.k.a. "Ariel" Power Button Driver
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+
+#define RESP_COUNTER(response) (response.header & 0x3)
+#define RESP_SIZE(response)((response.header >> 2) & 0x3)
+#define RESP_TYPE(response)((response.header >> 4) & 0xf)
+
+struct ec_input_response {
+ u8 reserved;
+ u8 header;
+ u8 data[3];
+} __packed;
+
+struct ariel_pwrbutton {
+ struct spi_device *client;
+ struct input_dev *input;
+ u8 msg_counter:2;
+};
+
+static int ec_input_read(struct ariel_pwrbutton *priv,
+ struct ec_input_response *response)
+{
+ u8 read_request[] = { 0x00, 0x5a, 0xa5, 0x00, 0x00 };
+ struct spi_device *spi = priv->client;
+ struct spi_transfer t = {
+ .tx_buf = read_request,
+ .rx_buf = response,
+ .len = sizeof(read_request),
+ };
+
+ compiletime_assert(sizeof(read_request) == sizeof(*response),
+ "SPI xfer request/response size mismatch");
+
+ return spi_sync_transfer(spi, , 1);
+}
+
+static irqreturn_t ec_input_interrupt(int irq, void *dev_id)
+{
+ struct ariel_pwrbutton *priv = dev_id;
+ struct spi_device *spi = priv->client;
+ struct ec_input_response response;
+ int i;
+
+ if (ec_input_read(priv, ) < 0) {
+ dev_err(>dev, "EC read failed.\n");
+ return IRQ_HANDLED;
+ }
+
+ if (priv->msg_counter == RESP_COUNTER(response)) {
+ dev_warn(>dev, "No new data to read?\n");
+ return IRQ_HANDLED;
+ }
+
+ priv->msg_counter = RESP_COUNTER(response);
+
+ if (RESP_TYPE(response) != 0x3 && RESP_TYPE(response) != 0xc) {
+ dev_dbg(>dev, "Ignoring message that's not kbd data\n");
+ return IRQ_HANDLED;
+ }
+
+ for (i = 0; i < RESP_SIZE
[PATCH v2 1/2] dt-bindings: input: Add Dell Wyse 3020 Power Button binding
Add binding document for the Dell Wyse 3020 a.k.a. "Ariel" Power Button.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v1:
- Collect Rob's R-b
.../bindings/input/ariel-pwrbutton.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
diff --git a/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
new file mode 100644
index 0..e022d36c48d23
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ariel-pwrbutton.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/ariel-pwrbutton.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dell Wyse 3020 a.k.a. "Ariel" Power Button
+
+maintainers:
+ - Lubomir Rintel
+
+description: |
+ The ENE Embedded Controller on the Ariel board has an interface to the
+ SPI bus that is capable of sending keyboard and mouse data. A single
+ power button is attached to it. This binding describes this
+ configuration.
+
+allOf:
+ - $ref: input.yaml#
+
+properties:
+ compatible:
+items:
+ - const: dell,wyse-ariel-ec-input
+ - const: ene,kb3930-input
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+power-button@0 {
+compatible = "dell,wyse-ariel-ec-input", "ene,kb3930-input";
+reg = <0>;
+interrupt-parent = <>;
+interrupts = <60 IRQ_TYPE_EDGE_RISING>;
+spi-max-frequency = <3300>;
+};
+};
--
2.28.0
[PATCH v2 0/2] Add driver for power button on Dell Wyse 3020
please consider applying the patches chained to this message. It's a rather simple driver for a power button on Dell Ariel board along with the Device Tree binding document. Compared to previous version, endianness issues are fixed and I connected a Reviewed-by for the binding doc that I failed to before. Change logs are present in individual patches. Note that this set is versioned "v2", but I've sent the previous version (both unversioned) out twice before, because I've forgotten about the previous submission before. Sorry if it caused a confusion. Thank you Lubo
Re: [PATCH v6 1/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
On Sun, Nov 01, 2020 at 06:39:22PM +0200, Laurent Pinchart wrote:
> Hi Lubomir,
>
> Thank you for the patch.
Thanks for the message. Some responses inline below.
> On Fri, Oct 30, 2020 at 04:07:59AM +0100, Lubomir Rintel wrote:
> > Himax HX8837 is a secondary display controller used to drive the panel
> > on OLPC platforms.
> >
> > Signed-off-by: Lubomir Rintel
> > Reviewed-by: Rob Herring
> >
> > ---
> > Changes since v4:
> > - Rob's Reviewed-by
> >
> > Changes since v3:
> > - Moved to bindings/display/
> > - Added the ports
> > - Converted to YAML
> > - Removed Pavel's Ack, because the changes are substantial
> >
> > Changes since v2:
> > - s/betweend/between/
> >
> > Changes since v1:
> > - s/load-gpio/load-gpios/
> > - Use interrupt bindings instead of gpio for the IRQ
> >
> > .../bindings/display/bridge/himax,hx8837.yaml | 96 +++
> > 1 file changed, 96 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> > b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> > new file mode 100644
> > index 0..f5b0a00f5089d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> > @@ -0,0 +1,96 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Copyright (C) 2018,2019,2020 Lubomir Rintel
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/himax,hx8837.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: HX8837 Display Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Lubomir Rintel
> > +
> > +properties:
> > + compatible:
> > +const: himax,hx8837
> > +
> > + reg:
> > +const: 0xd
> > +
> > + load-gpios:
> > +maxItems: 1
> > +description: GPIO specifier of DCON_LOAD pin (active high)
> > +
> > + stat-gpios:
> > +minItems: 2
> > +description: GPIO specifier of DCON_STAT0 and DCON_STAT1 pins (active
> > high)
> > +
> > + interrupts:
> > +maxItems: 1
> > +description: Interrupt specifier of DCON_IRQ pin (edge falling)
> > +
> > + ports:
> > +type: object
> > +
> > +properties:
> > + port@0:
> > +type: object
> > +description: |
> > + Video port for RGB input.
> > +
> > + port@1:
> > +type: object
> > +description: |
> > + Video port connected to the panel.
> > +
> > +required:
> > + - port@0
> > + - port@1
>
> No regulators ?
There are four.
On the OLPC platform they're controlled together by the EC.
I've added the supplies to the EC driver and looked into supporting them
properly in the driver and am finding it somehow tricky to do it properly.
I couldn't figure out what is the proper place to enable and disable the
regulators. Also drm_bridge_remove() just mercilessly tearing down the
bridge without ensuring it's not used anymore doesn't help us on driver
unbind.
I'm wondering if it's okay if I leave the driver without explicit
support for the power supplies for now, assuming that EC just takes
care of enabling the power and never disable it?
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - load-gpios
> > + - stat-gpios
>
> Do stat-gpios need to be mandatory ? The driver in patch 2/2 doesn't
> seem to use them, could we have boards where those signals are not
> connected to GPIOs ?
Perhaps not, in theory.
Pretty sure the OLPC machines are the only ones that utilize this
silicon though.
> > + - interrupts
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +
> > +i2c {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
>
> Could you please avoid spaces or tabs at end of lines ? There are three
> other occurrences below.
Ugh, I was sure I ran checkpatch.pl, but apparently not.
Sorry for that.
> > +lcd-controller@d {
> > +compatible = "himax,hx8837";
> > +reg = <0x0d>;
> > +stat-gpios = < 100 GPIO_ACTIVE_HIGH>,
> > +
Re: [PATCH v6 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Hello Sam,
thanks for your response.
On Sat, Oct 31, 2020 at 09:01:37AM +0100, Sam Ravnborg wrote:
> Hi Lubomir.
>
> On Fri, Oct 30, 2020 at 04:08:00AM +0100, Lubomir Rintel wrote:
> > Himax HX8837 is used to drive the LCD panel on OLPC platforms.
> >
> > It controls the panel backlight and is able to refresh it when the LCD
> > controller (and the rest of the plaform) is powered off.
> >
> > It also converts regular RGB color data from the LCDC so that it looks
> > reasonable on the OLPC LCD panel with a monochromatic layer on top of a
> > layer that can either reflect light (b/w sunlight readable mode) or light
> > pattern of red, green and blue pixels.
> >
> > At this point, the driver is rather basic. The self-refresh mode is not
> > supported. There's no way of independently controlling the color swizzling,
> > antialiasing or b/w conversion, but it probably isn't too useful either.
> >
> > There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
> > in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
> > DRM, so this driver doesn't replace the other one yet.
> >
> > Signed-off-by: Lubomir Rintel
> >
> > ---
> > Changes since v5:
> > (All based on feedback from Sam Ravnborg)
> > - Fix indentation in Kconfig
> > - Sort #includes
> > - Use a constant for max brightness instead of a literal
> > - Remove struct drm_panel from priv data
> > - Use dev_err() instead of DRM_ERROR
> > - Replace direct use of backlight props.brightness with
> > backlight_get_brightness()
> > - Document sentinels with { /* sentinel */ }
> > - Remove unsetting of panel->backlight
>
> Thanks, I missed a few things during the last round, so here is a few
> more comments. Only very trivial things but lets get them fixed before
> we add the driver to drm-misc-next.
>
> Sam
>
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index ef91646441b16..881780719af7c 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
> > on ARM-based platforms. Saying Y here when this driver is not needed
> > will not cause any issue.
> >
> > +config DRM_HIMAX_HX8837
> > + tristate "HiMax HX8837 OLPC Display Controller"
> > + depends on OF
> > + depends on OLPC || ARCH_MMP || COMPILE_TEST
> > + select DRM_KMS_HELPER
> > + select BACKLIGHT_LCD_SUPPORT
> Unknown symbol - "git grep BACKLIGHT_LCD_SUPPORT" only turned up one
> unrelated hit.
>
> > + select BACKLIGHT_CLASS_DEVICE
> Please use a depends - using select on a symbol with a prompt is always
> wrong. Yeah, I know you then need to enable backlight to see this
> driver. Sorry, but this is the best we can do now.
> Many other drivers can cope with depends here.
This results in a dependency loop:
drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by
DRM_HIMAX_HX8837
drivers/gpu/drm/bridge/Kconfig:51: symbol DRM_HIMAX_HX8837 depends on
BACKLIGHT_CLASS_DEVICE
drivers/video/backlight/Kconfig:143:symbol BACKLIGHT_CLASS_DEVICE is
selected by FB_BACKLIGHT
drivers/video/fbdev/Kconfig:187:symbol FB_BACKLIGHT depends on FB
Unfortunately I have no idea how to resolve it at the moment.
I suppose I can look further into it if necessary. Or is it okay if I
leave it at select BACKLIGHT_CLASS_DEVICE for now?
> > + help
> > + Enable support for HiMax HX8837 Display Controller as found in the
> > + OLPC XO laptops.
> > +
> > + If your laptop doesn't have green ears, say "N"
> I like this last comment :-)
>
> > +
> > config DRM_LONTIUM_LT9611
> > tristate "Lontium LT9611 DSI/HDMI bridge"
> > select SND_SOC_HDMI_CODEC if SND_SOC
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 2b3aff104e466..21f72df3260db 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,6 +2,7 @@
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> > +obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
> > obj-$(CONFIG_DRM_LONTI
[PATCH v6 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Himax HX8837 is used to drive the LCD panel on OLPC platforms.
It controls the panel backlight and is able to refresh it when the LCD
controller (and the rest of the plaform) is powered off.
It also converts regular RGB color data from the LCDC so that it looks
reasonable on the OLPC LCD panel with a monochromatic layer on top of a
layer that can either reflect light (b/w sunlight readable mode) or light
pattern of red, green and blue pixels.
At this point, the driver is rather basic. The self-refresh mode is not
supported. There's no way of independently controlling the color swizzling,
antialiasing or b/w conversion, but it probably isn't too useful either.
There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
DRM, so this driver doesn't replace the other one yet.
Signed-off-by: Lubomir Rintel
---
Changes since v5:
(All based on feedback from Sam Ravnborg)
- Fix indentation in Kconfig
- Sort #includes
- Use a constant for max brightness instead of a literal
- Remove struct drm_panel from priv data
- Use dev_err() instead of DRM_ERROR
- Replace direct use of backlight props.brightness with
backlight_get_brightness()
- Document sentinels with { /* sentinel */ }
- Remove unsetting of panel->backlight
Changes since v3:
- Added this patch, in place of a driver derived from
drivers/staging/olpc_dcon. Compared to the previous one this
implements the bare minimum, without the fancy stuff such as
self-refresh that need more work/thinking.
drivers/gpu/drm/bridge/Kconfig| 13 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/himax-hx8837.c | 330 ++
3 files changed, 344 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index ef91646441b16..881780719af7c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_HIMAX_HX8837
+ tristate "HiMax HX8837 OLPC Display Controller"
+ depends on OF
+ depends on OLPC || ARCH_MMP || COMPILE_TEST
+ select DRM_KMS_HELPER
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ Enable support for HiMax HX8837 Display Controller as found in the
+ OLPC XO laptops.
+
+ If your laptop doesn't have green ears, say "N"
+
config DRM_LONTIUM_LT9611
tristate "Lontium LT9611 DSI/HDMI bridge"
select SND_SOC_HDMI_CODEC if SND_SOC
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2b3aff104e466..21f72df3260db 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
b/drivers/gpu/drm/bridge/himax-hx8837.c
new file mode 100644
index 0..f472e16cc331d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/himax-hx8837.c
@@ -0,0 +1,330 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HiMax HX8837 Display Controller Driver
+ *
+ * Datasheet: http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define bridge_to_hx8837_priv(x) \
+ container_of(x, struct hx8837_priv, bridge)
+
+/* DCON registers */
+enum {
+ DCON_REG_ID = 0x00,
+ DCON_REG_MODE = 0x01,
+ DCON_REG_HRES = 0x02,
+ DCON_REG_HTOTAL = 0x03,
+ DCON_REG_HSYNC_WIDTH= 0x04,
+ DCON_REG_VRES = 0x05,
+ DCON_REG_VTOTAL = 0x06,
+ DCON_REG_VSYNC_WIDTH= 0x07,
+ DCON_REG_TIMEOUT= 0x08,
+ DCON_REG_SCAN_INT = 0x09,
+ DCON_REG_BRIGHT = 0x0a,
+ DCON_REG_MEM_OPT_A = 0x41,
+ DCON_REG_MEM_OPT_B = 0x42,
+};
+
+/* DCON_REG_MODE */
+enum {
+ MODE_PASSTHRU = BIT(0),
+ MODE_SLEEP = BIT(1),
+ MODE_SLEEP_AUTO = BIT(2),
+ MODE_BL_ENABLE = BIT(3),
+ MODE_BLANK = BIT(4),
+ MODE_CSWIZZLE = BIT(5),
+ MODE_COL_AA = BIT(6),
+ MODE_MONO_LUMA = BIT(7),
+ MODE_SCAN_INT = BIT(8),
+
[no subject]
Subject: [PATCH v6 0/2] Add a Himax HX8837 display controller driver Date: Sat, 26 Sep 2020 02:07:17 +0200 Message-ID: <20200926000719.229204-1-lkund...@v3.sk> (raw) Hi, please take a look at the patches chained to this messages and consider applying them. They add support for the controller that drives the panel on the OLPC XO laptops. Compared to v5, points risen in review by Sam Ravnborg have been addressed. Details in change log of patch 2/2. Tested on an OLPC XO-1.75 laptop. Thank you Lubo
[PATCH v6 1/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
Himax HX8837 is a secondary display controller used to drive the panel
on OLPC platforms.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v4:
- Rob's Reviewed-by
Changes since v3:
- Moved to bindings/display/
- Added the ports
- Converted to YAML
- Removed Pavel's Ack, because the changes are substantial
Changes since v2:
- s/betweend/between/
Changes since v1:
- s/load-gpio/load-gpios/
- Use interrupt bindings instead of gpio for the IRQ
.../bindings/display/bridge/himax,hx8837.yaml | 96 +++
1 file changed, 96 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
new file mode 100644
index 0..f5b0a00f5089d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2018,2019,2020 Lubomir Rintel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/himax,hx8837.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HX8837 Display Controller Device Tree Bindings
+
+maintainers:
+ - Lubomir Rintel
+
+properties:
+ compatible:
+const: himax,hx8837
+
+ reg:
+const: 0xd
+
+ load-gpios:
+maxItems: 1
+description: GPIO specifier of DCON_LOAD pin (active high)
+
+ stat-gpios:
+minItems: 2
+description: GPIO specifier of DCON_STAT0 and DCON_STAT1 pins (active high)
+
+ interrupts:
+maxItems: 1
+description: Interrupt specifier of DCON_IRQ pin (edge falling)
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for RGB input.
+
+ port@1:
+type: object
+description: |
+ Video port connected to the panel.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - load-gpios
+ - stat-gpios
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lcd-controller@d {
+compatible = "himax,hx8837";
+reg = <0x0d>;
+stat-gpios = < 100 GPIO_ACTIVE_HIGH>,
+ < 101 GPIO_ACTIVE_HIGH>;
+load-gpios = < 142 GPIO_ACTIVE_HIGH>;
+interrupts = < 124 IRQ_TYPE_EDGE_FALLING>;
+
+ports {
+#address-cells = <0x01>;
+#size-cells = <0x00>;
+
+port@0 {
+reg = <0x00>;
+dcon_rgb_in: endpoint {
+remote-endpoint = <_rgb_out>;
+};
+};
+
+port@1 {
+reg = <0x01>;
+dcon_gettl_out: endpoint {
+remote-endpoint = <_dettl_in>;
+};
+};
+};
+};
+};
--
2.28.0
Re: [RESEND PATCH v5 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Hello Sam, On Fri, Oct 16, 2020 at 10:07:34PM +0200, Sam Ravnborg wrote: > Hi Lubomir. > > On Sat, Sep 26, 2020 at 02:07:19AM +0200, Lubomir Rintel wrote: > > Himax HX8837 is used to drive the LCD panel on OLPC platforms. > > > > It controls the panel backlight and is able to refresh it when the LCD > > controller (and the rest of the plaform) is powered off. > > > > It also converts regular RGB color data from the LCDC so that it looks > > reasonable on the OLPC LCD panel with a monochromatic layer on top of a > > layer that can either reflect light (b/w sunlight readable mode) or light > > pattern of red, green and blue pixels. > > > > At this point, the driver is rather basic. The self-refresh mode is not > > supported. There's no way of independently controlling the color swizzling, > > antialiasing or b/w conversion, but it probably isn't too useful either. > > > > There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75 > > in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize > > DRM, so this driver doesn't replace the other one yet. > > > > Signed-off-by: Lubomir Rintel > > A little feedback follows. > > Sam > > > > > --- > > Changes since v3: > > - Added this patch, in place of a driver derived from > > drivers/staging/olpc_dcon. Compared to the previous one this > > implements the bare minimum, without the fancy stuff such as > > self-refresh that need more work/thinking. > > > > drivers/gpu/drm/bridge/Kconfig| 13 ++ > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/himax-hx8837.c | 325 ++ > > 3 files changed, 339 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c > > > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > > index ef91646441b16..6a923dd56c1d5 100644 > > --- a/drivers/gpu/drm/bridge/Kconfig > > +++ b/drivers/gpu/drm/bridge/Kconfig > > @@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR > > on ARM-based platforms. Saying Y here when this driver is not needed > > will not cause any issue. > > > > +config DRM_HIMAX_HX8837 > > +tristate "HiMax HX8837 OLPC Display Controller" > > + depends on OF > > + depends on OLPC || ARCH_MMP || COMPILE_TEST > > + select DRM_KMS_HELPER > > +select BACKLIGHT_LCD_SUPPORT > > +select BACKLIGHT_CLASS_DEVICE > > +help > > + Enable support for HiMax HX8837 Display Controller as found in > > the > > + OLPC XO laptops. > > + > > + If your laptop doesn't have green ears, say "N" > > There is a mixture of tabs and spaces for indent - use tabs only (and > tabs + 2 spaces for the help text). > > > > + > > config DRM_LONTIUM_LT9611 > > tristate "Lontium LT9611 DSI/HDMI bridge" > > select SND_SOC_HDMI_CODEC if SND_SOC > > diff --git a/drivers/gpu/drm/bridge/Makefile > > b/drivers/gpu/drm/bridge/Makefile > > index 2b3aff104e466..21f72df3260db 100644 > > --- a/drivers/gpu/drm/bridge/Makefile > > +++ b/drivers/gpu/drm/bridge/Makefile > > @@ -2,6 +2,7 @@ > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o > > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o > > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o > > +obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o > Please add in alphabetical order. > > > obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o > > obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += > > megachips-stdp-ge-b850v3-fw.o > > diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c > > b/drivers/gpu/drm/bridge/himax-hx8837.c > > new file mode 100644 > > index 0..1e97fcb8ce505 > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/himax-hx8837.c > > @@ -0,0 +1,325 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > +/* > > + * HiMax HX8837 Display Controller Driver > > + * > > + * Datasheet: > > http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf > > + * > > + * Copyright (C) 2020 Lubomir Rintel > > + */ > > + > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > In blocks are good but please add them in alphabetica
Re: [PATCH 6/6] dt-bindings: misc: correct the property name cmd-gpios to cmd-gpio
Hi,
On Wed, Oct 14, 2020 at 12:08:45AM +0800, Zhen Lei wrote:
> The property name used in arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts is
> cmd-gpio.
>
> arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:235:
> cmd-gpio = < 155 GPIO_ACTIVE_HIGH>;
>
> Signed-off-by: Zhen Lei
Thanks for the patch.
I've sent out an equivalent one some time ago:
https://lore.kernel.org/lkml/20200925234805.228251-3-lkund...@v3.sk/
In any case, either is fine with me.
Acked-by: Lubomir Rintel
> ---
> Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
> b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
> index b3c45c046ba5e37..c7a06a9650db2ed 100644
> --- a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
> +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.yaml
> @@ -24,7 +24,7 @@ properties:
>compatible:
> const: olpc,xo1.75-ec
>
> - cmd-gpios:
> + cmd-gpio:
> description: GPIO uspecifier of the CMD pin
> maxItems: 1
>
> @@ -32,7 +32,7 @@ properties:
>
> required:
>- compatible
> - - cmd-gpios
> + - cmd-gpio
>
> additionalProperties: false
>
> @@ -49,7 +49,7 @@ examples:
>slave {
> compatible = "olpc,xo1.75-ec";
> spi-cpha;
> -cmd-gpios = < 155 GPIO_ACTIVE_HIGH>;
> +cmd-gpio = < 155 GPIO_ACTIVE_HIGH>;
>};
> };
>
> --
> 1.8.3
>
>
[RESEND PATCH v5 0/2] Add a Himax HX8837 display controller driver
Hi, please take a look at the patches chained to this messages and consider applying them. They add support for the controller that drives the panel on the OLPC XO laptops. The only change since the previous version is the Reviewed-by tag in DT bindings. Compared to v3 the bindings have been converted to YAML and the driver itself has been rewritten without any fancy features such as the self-refresh so that the bare minimum works before the rest can be figured out. Detailed change logs are in individual patches. Tested on an OLPC XO-1.75 laptop. Thank you Lubo
[RESEND PATCH v5 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Himax HX8837 is used to drive the LCD panel on OLPC platforms.
It controls the panel backlight and is able to refresh it when the LCD
controller (and the rest of the plaform) is powered off.
It also converts regular RGB color data from the LCDC so that it looks
reasonable on the OLPC LCD panel with a monochromatic layer on top of a
layer that can either reflect light (b/w sunlight readable mode) or light
pattern of red, green and blue pixels.
At this point, the driver is rather basic. The self-refresh mode is not
supported. There's no way of independently controlling the color swizzling,
antialiasing or b/w conversion, but it probably isn't too useful either.
There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
DRM, so this driver doesn't replace the other one yet.
Signed-off-by: Lubomir Rintel
---
Changes since v3:
- Added this patch, in place of a driver derived from
drivers/staging/olpc_dcon. Compared to the previous one this
implements the bare minimum, without the fancy stuff such as
self-refresh that need more work/thinking.
drivers/gpu/drm/bridge/Kconfig| 13 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/himax-hx8837.c | 325 ++
3 files changed, 339 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index ef91646441b16..6a923dd56c1d5 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_HIMAX_HX8837
+tristate "HiMax HX8837 OLPC Display Controller"
+ depends on OF
+ depends on OLPC || ARCH_MMP || COMPILE_TEST
+ select DRM_KMS_HELPER
+select BACKLIGHT_LCD_SUPPORT
+select BACKLIGHT_CLASS_DEVICE
+help
+ Enable support for HiMax HX8837 Display Controller as found in the
+ OLPC XO laptops.
+
+ If your laptop doesn't have green ears, say "N"
+
config DRM_LONTIUM_LT9611
tristate "Lontium LT9611 DSI/HDMI bridge"
select SND_SOC_HDMI_CODEC if SND_SOC
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 2b3aff104e466..21f72df3260db 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
b/drivers/gpu/drm/bridge/himax-hx8837.c
new file mode 100644
index 0..1e97fcb8ce505
--- /dev/null
+++ b/drivers/gpu/drm/bridge/himax-hx8837.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HiMax HX8837 Display Controller Driver
+ *
+ * Datasheet: http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define bridge_to_hx8837_priv(x) \
+ container_of(x, struct hx8837_priv, bridge)
+
+/* DCON registers */
+enum {
+ DCON_REG_ID = 0x00,
+ DCON_REG_MODE = 0x01,
+ DCON_REG_HRES = 0x02,
+ DCON_REG_HTOTAL = 0x03,
+ DCON_REG_HSYNC_WIDTH= 0x04,
+ DCON_REG_VRES = 0x05,
+ DCON_REG_VTOTAL = 0x06,
+ DCON_REG_VSYNC_WIDTH= 0x07,
+ DCON_REG_TIMEOUT= 0x08,
+ DCON_REG_SCAN_INT = 0x09,
+ DCON_REG_BRIGHT = 0x0a,
+ DCON_REG_MEM_OPT_A = 0x41,
+ DCON_REG_MEM_OPT_B = 0x42,
+};
+
+/* DCON_REG_MODE */
+enum {
+ MODE_PASSTHRU = BIT(0),
+ MODE_SLEEP = BIT(1),
+ MODE_SLEEP_AUTO = BIT(2),
+ MODE_BL_ENABLE = BIT(3),
+ MODE_BLANK = BIT(4),
+ MODE_CSWIZZLE = BIT(5),
+ MODE_COL_AA = BIT(6),
+ MODE_MONO_LUMA = BIT(7),
+ MODE_SCAN_INT = BIT(8),
+ MODE_CLOCKDIV = BIT(9),
+ MODE_DEBUG = BIT(14),
+ MODE_SELFTEST = BIT(15),
+};
+
+struct hx8837_priv {
+ struct regmap *regmap;
+ struct gpio_desc *load_gpio;
+
+ struct drm_bridge *panel_bridge;
+ struct drm_panel *panel;
+ struct drm_bridge bridge;
+};
+
+static int hx8837_bridge_attach(struct drm_bridge *bridge,
+
[RESEND PATCH v5 1/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
Himax HX8837 is a secondary display controller used to drive the panel
on OLPC platforms.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v4:
- Rob's Reviewed-by
Changes since v3:
- Moved to bindings/display/
- Added the ports
- Converted to YAML
- Removed Pavel's Ack, because the changes are substantial
Changes since v2:
- s/betweend/between/
Changes since v1:
- s/load-gpio/load-gpios/
- Use interrupt bindings instead of gpio for the IRQ
.../bindings/display/bridge/himax,hx8837.yaml | 96 +++
1 file changed, 96 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
new file mode 100644
index 0..f5b0a00f5089d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2018,2019,2020 Lubomir Rintel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/himax,hx8837.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HX8837 Display Controller Device Tree Bindings
+
+maintainers:
+ - Lubomir Rintel
+
+properties:
+ compatible:
+const: himax,hx8837
+
+ reg:
+const: 0xd
+
+ load-gpios:
+maxItems: 1
+description: GPIO specifier of DCON_LOAD pin (active high)
+
+ stat-gpios:
+minItems: 2
+description: GPIO specifier of DCON_STAT0 and DCON_STAT1 pins (active high)
+
+ interrupts:
+maxItems: 1
+description: Interrupt specifier of DCON_IRQ pin (edge falling)
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for RGB input.
+
+ port@1:
+type: object
+description: |
+ Video port connected to the panel.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - load-gpios
+ - stat-gpios
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lcd-controller@d {
+compatible = "himax,hx8837";
+reg = <0x0d>;
+stat-gpios = < 100 GPIO_ACTIVE_HIGH>,
+ < 101 GPIO_ACTIVE_HIGH>;
+load-gpios = < 142 GPIO_ACTIVE_HIGH>;
+interrupts = < 124 IRQ_TYPE_EDGE_FALLING>;
+
+ports {
+#address-cells = <0x01>;
+#size-cells = <0x00>;
+
+port@0 {
+reg = <0x00>;
+dcon_rgb_in: endpoint {
+remote-endpoint = <_rgb_out>;
+};
+};
+
+port@1 {
+reg = <0x01>;
+dcon_gettl_out: endpoint {
+remote-endpoint = <_dettl_in>;
+};
+};
+};
+};
+};
--
2.26.2
[RESEND 2 PATCH v3 0/3] phy: Add USB HSIC PHY driver for Marvell MMP3 SoC
Hi, please consider applying this patch set. It adds the HSIC PHY driver for Marvell MMP3 along with related DT binding changes. In response to previous submission it was suggested that a cast of private data be removed, but it actually serves a purpose: https://lore.kernel.org/lkml/20200903201404.GA115604@demiurge.local/ Thank you, Lubo
[RESEND 2 PATCH v3 3/3] phy: Add USB HSIC PHY driver for Marvell MMP3 SoC
Add PHY driver for the HSICs found on Marvell MMP3 SoC. The driver is
rather straightforward -- the PHY essentially just needs to be enabled.
Signed-off-by: Lubomir Rintel
---
Changes since v1:
- Explicitely cast drvdata pointer to make sparse happy
drivers/phy/marvell/Kconfig | 12 +
drivers/phy/marvell/Makefile| 1 +
drivers/phy/marvell/phy-mmp3-hsic.c | 82 +
3 files changed, 95 insertions(+)
create mode 100644 drivers/phy/marvell/phy-mmp3-hsic.c
diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
index 8f6273c837ec3..6c96f2bf52665 100644
--- a/drivers/phy/marvell/Kconfig
+++ b/drivers/phy/marvell/Kconfig
@@ -116,3 +116,15 @@ config PHY_MMP3_USB
The PHY driver will be used by Marvell udc/ehci/otg driver.
To compile this driver as a module, choose M here.
+
+config PHY_MMP3_HSIC
+ tristate "Marvell MMP3 USB HSIC PHY Driver"
+ depends on MACH_MMP3_DT || COMPILE_TEST
+ select GENERIC_PHY
+ help
+ Enable this to support Marvell MMP3 USB HSIC PHY driver for
+ Marvell MMP3 SoC. This driver will be used my the Marvell EHCI
+ driver to initialize the interface to internal USB HSIC
+ components on MMP3-based boards.
+
+ To compile this driver as a module, choose M here.
diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
index 5a106b1549f41..7f296ef028292 100644
--- a/drivers/phy/marvell/Makefile
+++ b/drivers/phy/marvell/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
obj-$(CONFIG_PHY_MMP3_USB) += phy-mmp3-usb.o
+obj-$(CONFIG_PHY_MMP3_HSIC)+= phy-mmp3-hsic.o
obj-$(CONFIG_PHY_MVEBU_A3700_COMPHY) += phy-mvebu-a3700-comphy.o
obj-$(CONFIG_PHY_MVEBU_A3700_UTMI) += phy-mvebu-a3700-utmi.o
obj-$(CONFIG_PHY_MVEBU_A38X_COMPHY)+= phy-armada38x-comphy.o
diff --git a/drivers/phy/marvell/phy-mmp3-hsic.c
b/drivers/phy/marvell/phy-mmp3-hsic.c
new file mode 100644
index 0..47c1e8894939f
--- /dev/null
+++ b/drivers/phy/marvell/phy-mmp3-hsic.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define HSIC_CTRL 0x08
+#define HSIC_ENABLEBIT(7)
+#define PLL_BYPASS BIT(4)
+
+static int mmp3_hsic_phy_init(struct phy *phy)
+{
+ void __iomem *base = (void __iomem *)phy_get_drvdata(phy);
+ u32 hsic_ctrl;
+
+ hsic_ctrl = readl_relaxed(base + HSIC_CTRL);
+ hsic_ctrl |= HSIC_ENABLE;
+ hsic_ctrl |= PLL_BYPASS;
+ writel_relaxed(hsic_ctrl, base + HSIC_CTRL);
+
+ return 0;
+}
+
+static const struct phy_ops mmp3_hsic_phy_ops = {
+ .init = mmp3_hsic_phy_init,
+ .owner = THIS_MODULE,
+};
+
+static const struct of_device_id mmp3_hsic_phy_of_match[] = {
+ { .compatible = "marvell,mmp3-hsic-phy", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, mmp3_hsic_phy_of_match);
+
+static int mmp3_hsic_phy_probe(struct platform_device *pdev)
+{
+ struct device *dev = >dev;
+ struct phy_provider *provider;
+ struct resource *resource;
+ void __iomem *base;
+ struct phy *phy;
+
+ resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ base = devm_ioremap_resource(dev, resource);
+ if (IS_ERR(base)) {
+ dev_err(dev, "failed to remap PHY regs\n");
+ return PTR_ERR(base);
+ }
+
+ phy = devm_phy_create(dev, NULL, _hsic_phy_ops);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create PHY\n");
+ return PTR_ERR(phy);
+ }
+
+ phy_set_drvdata(phy, (void *)base);
+ provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ if (IS_ERR(provider)) {
+ dev_err(dev, "failed to register PHY provider\n");
+ return PTR_ERR(provider);
+ }
+
+ return 0;
+}
+
+static struct platform_driver mmp3_hsic_phy_driver = {
+ .probe = mmp3_hsic_phy_probe,
+ .driver = {
+ .name = "mmp3-hsic-phy",
+ .of_match_table = mmp3_hsic_phy_of_match,
+ },
+};
+module_platform_driver(mmp3_hsic_phy_driver);
+
+MODULE_AUTHOR("Lubomir Rintel ");
+MODULE_DESCRIPTION("Marvell MMP3 USB HSIC PHY Driver");
+MODULE_LICENSE("GPL");
--
2.26.2
[RESEND 2 PATCH v3 2/3] dt-bindings: phy: Allow BSD licensing of marvell,mmp3-hsic-phy.yaml
I wrote this binding and I'm fine with it being GPL + BSD dual-licensed, as is recommended for new DT bindings. Signed-off-by: Lubomir Rintel Acked-by: Rob Herring --- Changes since v2: - Add Rob's ack .../devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml index 30e290c579308..ff255aa4cc103 100644 --- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-or-later +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) # Copyright 2019 Lubomir Rintel %YAML 1.2 --- -- 2.26.2
[RESEND 2 PATCH v3 1/3] dt-bindings: phy: Drop reset-gpios from marvell,mmp3-hsic-phy
This has been added in error -- the PHY block doesn't have a reset pin.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v2:
- Add Rob's Reviewed-by tag
.../devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml | 7 ---
1 file changed, 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
index 00609ace677c9..30e290c579308 100644
--- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml
@@ -18,27 +18,20 @@ properties:
maxItems: 1
description: base address of the device
- reset-gpios:
-maxItems: 1
-description: GPIO connected to reset
-
"#phy-cells":
const: 0
required:
- compatible
- reg
- - reset-gpios
- "#phy-cells"
additionalProperties: false
examples:
- |
-#include
hsic-phy@f0001800 {
compatible = "marvell,mmp3-hsic-phy";
reg = <0xf0001800 0x40>;
-reset-gpios = < 63 GPIO_ACTIVE_HIGH>;
#phy-cells = <0>;
};
--
2.26.2
[PATCH] clk: mmp2: Fix the display clock divider base
The LCD clock dividers are apparently based on one. No datasheet,
determined empirically, but seems to be confirmed by line 19 of lcd.fth in
OLPC laptop's Open Firmware [1]:
h# 0700 value pmua-disp-clk-sel \ PLL1 / 7 -> 113.86 MHz
[1]
https://raw.githubusercontent.com/quozl/openfirmware/65a08a73b2cac/cpu/arm/olpc/lcd.fth
Signed-off-by: Lubomir Rintel
---
drivers/clk/mmp/clk-of-mmp2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mmp/clk-of-mmp2.c b/drivers/clk/mmp/clk-of-mmp2.c
index 67208aea94c5c..0839fb2049e94 100644
--- a/drivers/clk/mmp/clk-of-mmp2.c
+++ b/drivers/clk/mmp/clk-of-mmp2.c
@@ -347,9 +347,9 @@ static struct mmp_param_mux_clk mmp3_apmu_mux_clks[] = {
};
static struct mmp_param_div_clk apmu_div_clks[] = {
- {0, "disp0_div", "disp0_mux", CLK_SET_RATE_PARENT, APMU_DISP0, 8, 4, 0,
_lock},
+ {0, "disp0_div", "disp0_mux", CLK_SET_RATE_PARENT, APMU_DISP0, 8, 4,
CLK_DIVIDER_ONE_BASED, _lock},
{0, "disp0_sphy_div", "disp0_mux", CLK_SET_RATE_PARENT, APMU_DISP0, 15,
5, 0, _lock},
- {0, "disp1_div", "disp1_mux", CLK_SET_RATE_PARENT, APMU_DISP1, 8, 4, 0,
_lock},
+ {0, "disp1_div", "disp1_mux", CLK_SET_RATE_PARENT, APMU_DISP1, 8, 4,
CLK_DIVIDER_ONE_BASED, _lock},
{0, "ccic0_sphy_div", "ccic0_mix_clk", CLK_SET_RATE_PARENT, APMU_CCIC0,
10, 5, 0, _lock},
{0, "ccic1_sphy_div", "ccic1_mix_clk", CLK_SET_RATE_PARENT, APMU_CCIC1,
10, 5, 0, _lock},
};
--
2.26.2
[PATCH 2/2] ARM: dts: mmp2-olpc-xo-1-75: Use plural form of "-gpios"
This makes validation happier.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
index f1a41152e9dd7..adde62d6fce73 100644
--- a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
+++ b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
@@ -227,12 +227,12 @@ {
/delete-property/ #size-cells;
spi-slave;
status = "okay";
- ready-gpio = < 125 GPIO_ACTIVE_HIGH>;
+ ready-gpios = < 125 GPIO_ACTIVE_HIGH>;
slave {
compatible = "olpc,xo1.75-ec";
spi-cpha;
- cmd-gpio = < 155 GPIO_ACTIVE_HIGH>;
+ cmd-gpios = < 155 GPIO_ACTIVE_HIGH>;
};
};
--
2.26.2
[PATCH 1/2] ARM: dts: mmp3: Add power domain for the camera
The camera interfaces on MMP3 are on a separate power island that needs
to be turned on for them to operate and, ideally, turned off when the
cameras are not in use.
This hooks the power island with the camera interfaces in the device
tree.
Signed-off-by: Lubomir Rintel
---
arch/arm/boot/dts/mmp3.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mmp3.dtsi b/arch/arm/boot/dts/mmp3.dtsi
index cc4efd0efabd2..4ae630d37d094 100644
--- a/arch/arm/boot/dts/mmp3.dtsi
+++ b/arch/arm/boot/dts/mmp3.dtsi
@@ -296,6 +296,7 @@ camera0: camera@d420a000 {
interrupts = ;
clocks = <_clocks MMP2_CLK_CCIC0>;
clock-names = "axi";
+ power-domains = <_clocks
MMP3_POWER_DOMAIN_CAMERA>;
#clock-cells = <0>;
clock-output-names = "mclk";
status = "disabled";
@@ -307,6 +308,7 @@ camera1: camera@d420a800 {
interrupts = ;
clocks = <_clocks MMP2_CLK_CCIC1>;
clock-names = "axi";
+ power-domains = <_clocks
MMP3_POWER_DOMAIN_CAMERA>;
#clock-cells = <0>;
clock-output-names = "mclk";
status = "disabled";
--
2.26.2
[PATCH 0/2] ARM: dts: A couple of mmp devicetree updates
Hi, please take a look at two patches chaned to this message and consider applying them to arm/dt. Thank you Lubo
Re: [PATCH -next] media: marvell-ccic: Fix -Wunused-function warnings
On Thu, Sep 10, 2020 at 05:18:15PM +0800, Yuehaibing wrote:
> On 2020/9/10 16:22, Lubomir Rintel wrote:
> > On Thu, Sep 10, 2020 at 04:09:33PM +0800, YueHaibing wrote:
> >> If CONFIG_PM is n, gcc warns:
> >>
> >> drivers/media/platform/marvell-ccic/mmp-driver.c:347:12: warning:
> >> ‘mmpcam_resume’ defined but not used [-Wunused-function]
> >> static int mmpcam_resume(struct device *dev)
> >> ^
> >> drivers/media/platform/marvell-ccic/mmp-driver.c:338:12: warning:
> >> ‘mmpcam_suspend’ defined but not used [-Wunused-function]
> >> static int mmpcam_suspend(struct device *dev)
> >> ^~
> >> drivers/media/platform/marvell-ccic/mmp-driver.c:324:12: warning:
> >> ‘mmpcam_runtime_suspend’ defined but not used [-Wunused-function]
> >> static int mmpcam_runtime_suspend(struct device *dev)
> >> ^~
> >> drivers/media/platform/marvell-ccic/mmp-driver.c:310:12: warning:
> >> ‘mmpcam_runtime_resume’ defined but not used [-Wunused-function]
> >> static int mmpcam_runtime_resume(struct device *dev)
> >> ^
> >>
> >> Mark them as __maybe_unused to fix this.
> >>
> >> Reported-by: Hulk Robot
> >> Signed-off-by: YueHaibing
> >
> > Your colleague seems to sent out an equivalent patch:
> > https://lore.kernel.org/lkml/20200910080933.40684-1-yuehaib...@huawei.com/
>
> This is my patch, paste an wrong link?
Indeed, sorry for the confusion.
The original mail only went to linux-media, not lkml, which is why I
picked the wrong one from the archive. Here's the patch:
https://lore.kernel.org/linux-media/20200909112921.5116-1-weiyongj...@huawei.com/
Take care
Lubo
>
> >
> > Cheers
> > Lubo
> >
> >> ---
> >> drivers/media/platform/marvell-ccic/mmp-driver.c | 8
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
> >> b/drivers/media/platform/marvell-ccic/mmp-driver.c
> >> index c4b28a00a3a2..032fdddbbecc 100644
> >> --- a/drivers/media/platform/marvell-ccic/mmp-driver.c
> >> +++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
> >> @@ -307,7 +307,7 @@ static int mmpcam_platform_remove(struct
> >> platform_device *pdev)
> >> * Suspend/resume support.
> >> */
> >>
> >> -static int mmpcam_runtime_resume(struct device *dev)
> >> +static int __maybe_unused mmpcam_runtime_resume(struct device *dev)
> >> {
> >>struct mmp_camera *cam = dev_get_drvdata(dev);
> >>struct mcam_camera *mcam = >mcam;
> >> @@ -321,7 +321,7 @@ static int mmpcam_runtime_resume(struct device *dev)
> >>return 0;
> >> }
> >>
> >> -static int mmpcam_runtime_suspend(struct device *dev)
> >> +static int __maybe_unused mmpcam_runtime_suspend(struct device *dev)
> >> {
> >>struct mmp_camera *cam = dev_get_drvdata(dev);
> >>struct mcam_camera *mcam = >mcam;
> >> @@ -335,7 +335,7 @@ static int mmpcam_runtime_suspend(struct device *dev)
> >>return 0;
> >> }
> >>
> >> -static int mmpcam_suspend(struct device *dev)
> >> +static int __maybe_unused mmpcam_suspend(struct device *dev)
> >> {
> >>struct mmp_camera *cam = dev_get_drvdata(dev);
> >>
> >> @@ -344,7 +344,7 @@ static int mmpcam_suspend(struct device *dev)
> >>return 0;
> >> }
> >>
> >> -static int mmpcam_resume(struct device *dev)
> >> +static int __maybe_unused mmpcam_resume(struct device *dev)
> >> {
> >>struct mmp_camera *cam = dev_get_drvdata(dev);
> >>
> >> --
> >> 2.17.1
> >>
> >>
> >
> > .
> >
>
Re: [PATCH -next] media: marvell-ccic: Fix -Wunused-function warnings
On Thu, Sep 10, 2020 at 04:09:33PM +0800, YueHaibing wrote:
> If CONFIG_PM is n, gcc warns:
>
> drivers/media/platform/marvell-ccic/mmp-driver.c:347:12: warning:
> ‘mmpcam_resume’ defined but not used [-Wunused-function]
> static int mmpcam_resume(struct device *dev)
> ^
> drivers/media/platform/marvell-ccic/mmp-driver.c:338:12: warning:
> ‘mmpcam_suspend’ defined but not used [-Wunused-function]
> static int mmpcam_suspend(struct device *dev)
> ^~
> drivers/media/platform/marvell-ccic/mmp-driver.c:324:12: warning:
> ‘mmpcam_runtime_suspend’ defined but not used [-Wunused-function]
> static int mmpcam_runtime_suspend(struct device *dev)
> ^~
> drivers/media/platform/marvell-ccic/mmp-driver.c:310:12: warning:
> ‘mmpcam_runtime_resume’ defined but not used [-Wunused-function]
> static int mmpcam_runtime_resume(struct device *dev)
> ^
>
> Mark them as __maybe_unused to fix this.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Your colleague seems to sent out an equivalent patch:
https://lore.kernel.org/lkml/20200910080933.40684-1-yuehaib...@huawei.com/
Cheers
Lubo
> ---
> drivers/media/platform/marvell-ccic/mmp-driver.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/marvell-ccic/mmp-driver.c
> b/drivers/media/platform/marvell-ccic/mmp-driver.c
> index c4b28a00a3a2..032fdddbbecc 100644
> --- a/drivers/media/platform/marvell-ccic/mmp-driver.c
> +++ b/drivers/media/platform/marvell-ccic/mmp-driver.c
> @@ -307,7 +307,7 @@ static int mmpcam_platform_remove(struct platform_device
> *pdev)
> * Suspend/resume support.
> */
>
> -static int mmpcam_runtime_resume(struct device *dev)
> +static int __maybe_unused mmpcam_runtime_resume(struct device *dev)
> {
> struct mmp_camera *cam = dev_get_drvdata(dev);
> struct mcam_camera *mcam = >mcam;
> @@ -321,7 +321,7 @@ static int mmpcam_runtime_resume(struct device *dev)
> return 0;
> }
>
> -static int mmpcam_runtime_suspend(struct device *dev)
> +static int __maybe_unused mmpcam_runtime_suspend(struct device *dev)
> {
> struct mmp_camera *cam = dev_get_drvdata(dev);
> struct mcam_camera *mcam = >mcam;
> @@ -335,7 +335,7 @@ static int mmpcam_runtime_suspend(struct device *dev)
> return 0;
> }
>
> -static int mmpcam_suspend(struct device *dev)
> +static int __maybe_unused mmpcam_suspend(struct device *dev)
> {
> struct mmp_camera *cam = dev_get_drvdata(dev);
>
> @@ -344,7 +344,7 @@ static int mmpcam_suspend(struct device *dev)
> return 0;
> }
>
> -static int mmpcam_resume(struct device *dev)
> +static int __maybe_unused mmpcam_resume(struct device *dev)
> {
> struct mmp_camera *cam = dev_get_drvdata(dev);
>
> --
> 2.17.1
>
>
Re: [PATCH -next] mfd: ene-kb3930: Make symbol 'kb3930_power_off' static
On Wed, Sep 09, 2020 at 10:32:53PM +0800, Wei Yongjun wrote:
> The sparse tool complains as follows:
>
> drivers/mfd/ene-kb3930.c:36:15: warning:
> symbol 'kb3930_power_off' was not declared. Should it be static?
>
> This variable is not used outside of ene-kb3930.c, this commit
> marks it static.
>
> Fixes: 753bd752e181 ("mfd: ene-kb3930: Add driver for ENE KB3930 Embedded
> Controller")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
Acked-by: Lubomir Rintel
Thank you!
Lubo
> ---
> drivers/mfd/ene-kb3930.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/ene-kb3930.c b/drivers/mfd/ene-kb3930.c
> index 1c32ff586816..eb7312bd6361 100644
> --- a/drivers/mfd/ene-kb3930.c
> +++ b/drivers/mfd/ene-kb3930.c
> @@ -33,7 +33,7 @@ struct kb3930 {
> struct gpio_descs *off_gpios;
> };
>
> -struct kb3930 *kb3930_power_off;
> +static struct kb3930 *kb3930_power_off;
>
> #define EC_GPIO_WAVE 0
> #define EC_GPIO_OFF_MODE 1
>
[PATCH v5 0/2] Add a Himax HX8837 display controller driver
Hi, please take a look at the patches chained to this messages and consider applying them. They add support for the controller that drives the panel on the OLPC XO laptops. The only change since the previous version is the Reviewed-by tag in DT bindings. Compared to v3 the bindings have been converted to YAML and the driver itself has been rewritten without any fancy features such as the self-refresh so that the bare minimum works before the rest can be figured out. Detailed change logs are in individual patches. Tested on an OLPC XO-1.75 laptop. Thank you Lubo
[PATCH v5 1/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
Himax HX8837 is a secondary display controller used to drive the panel
on OLPC platforms.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v4:
- Rob's Reviewed-by
Changes since v3:
- Moved to bindings/display/
- Added the ports
- Converted to YAML
- Removed Pavel's Ack, because the changes are substantial
Changes since v2:
- s/betweend/between/
Changes since v1:
- s/load-gpio/load-gpios/
- Use interrupt bindings instead of gpio for the IRQ
.../bindings/display/bridge/himax,hx8837.yaml | 96 +++
1 file changed, 96 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
new file mode 100644
index 0..f5b0a00f5089d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2018,2019,2020 Lubomir Rintel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/himax,hx8837.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HX8837 Display Controller Device Tree Bindings
+
+maintainers:
+ - Lubomir Rintel
+
+properties:
+ compatible:
+const: himax,hx8837
+
+ reg:
+const: 0xd
+
+ load-gpios:
+maxItems: 1
+description: GPIO specifier of DCON_LOAD pin (active high)
+
+ stat-gpios:
+minItems: 2
+description: GPIO specifier of DCON_STAT0 and DCON_STAT1 pins (active high)
+
+ interrupts:
+maxItems: 1
+description: Interrupt specifier of DCON_IRQ pin (edge falling)
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for RGB input.
+
+ port@1:
+type: object
+description: |
+ Video port connected to the panel.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - load-gpios
+ - stat-gpios
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lcd-controller@d {
+compatible = "himax,hx8837";
+reg = <0x0d>;
+stat-gpios = < 100 GPIO_ACTIVE_HIGH>,
+ < 101 GPIO_ACTIVE_HIGH>;
+load-gpios = < 142 GPIO_ACTIVE_HIGH>;
+interrupts = < 124 IRQ_TYPE_EDGE_FALLING>;
+
+ports {
+#address-cells = <0x01>;
+#size-cells = <0x00>;
+
+port@0 {
+reg = <0x00>;
+dcon_rgb_in: endpoint {
+remote-endpoint = <_rgb_out>;
+};
+};
+
+port@1 {
+reg = <0x01>;
+dcon_gettl_out: endpoint {
+remote-endpoint = <_dettl_in>;
+};
+};
+};
+};
+};
--
2.26.2
[PATCH v5 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Himax HX8837 is used to drive the LCD panel on OLPC platforms.
It controls the panel backlight and is able to refresh it when the LCD
controller (and the rest of the plaform) is powered off.
It also converts regular RGB color data from the LCDC so that it looks
reasonable on the OLPC LCD panel with a monochromatic layer on top of a
layer that can either reflect light (b/w sunlight readable mode) or light
pattern of red, green and blue pixels.
At this point, the driver is rather basic. The self-refresh mode is not
supported. There's no way of independently controlling the color swizzling,
antialiasing or b/w conversion, but it probably isn't too useful either.
There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
DRM, so this driver doesn't replace the other one yet.
Signed-off-by: Lubomir Rintel
---
Changes since v3:
- Added this patch, in place of a driver derived from
drivers/staging/olpc_dcon. Compared to the previous one this
implements the bare minimum, without the fancy stuff such as
self-refresh that need more work/thinking.
drivers/gpu/drm/bridge/Kconfig| 13 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/himax-hx8837.c | 325 ++
3 files changed, 339 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fce..df30d61c3fee1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_HIMAX_HX8837
+tristate "HiMax HX8837 OLPC Display Controller"
+ depends on OF
+ depends on OLPC || ARCH_MMP || COMPILE_TEST
+ select DRM_KMS_HELPER
+select BACKLIGHT_LCD_SUPPORT
+select BACKLIGHT_CLASS_DEVICE
+help
+ Enable support for HiMax HX8837 Display Controller as found in the
+ OLPC XO laptops.
+
+ If your laptop doesn't have green ears, say "N"
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e43473..70d97c84382d5 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
b/drivers/gpu/drm/bridge/himax-hx8837.c
new file mode 100644
index 0..1e97fcb8ce505
--- /dev/null
+++ b/drivers/gpu/drm/bridge/himax-hx8837.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HiMax HX8837 Display Controller Driver
+ *
+ * Datasheet: http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define bridge_to_hx8837_priv(x) \
+ container_of(x, struct hx8837_priv, bridge)
+
+/* DCON registers */
+enum {
+ DCON_REG_ID = 0x00,
+ DCON_REG_MODE = 0x01,
+ DCON_REG_HRES = 0x02,
+ DCON_REG_HTOTAL = 0x03,
+ DCON_REG_HSYNC_WIDTH= 0x04,
+ DCON_REG_VRES = 0x05,
+ DCON_REG_VTOTAL = 0x06,
+ DCON_REG_VSYNC_WIDTH= 0x07,
+ DCON_REG_TIMEOUT= 0x08,
+ DCON_REG_SCAN_INT = 0x09,
+ DCON_REG_BRIGHT = 0x0a,
+ DCON_REG_MEM_OPT_A = 0x41,
+ DCON_REG_MEM_OPT_B = 0x42,
+};
+
+/* DCON_REG_MODE */
+enum {
+ MODE_PASSTHRU = BIT(0),
+ MODE_SLEEP = BIT(1),
+ MODE_SLEEP_AUTO = BIT(2),
+ MODE_BL_ENABLE = BIT(3),
+ MODE_BLANK = BIT(4),
+ MODE_CSWIZZLE = BIT(5),
+ MODE_COL_AA = BIT(6),
+ MODE_MONO_LUMA = BIT(7),
+ MODE_SCAN_INT = BIT(8),
+ MODE_CLOCKDIV = BIT(9),
+ MODE_DEBUG = BIT(14),
+ MODE_SELFTEST = BIT(15),
+};
+
+struct hx8837_priv {
+ struct regmap *regmap;
+ struct gpio_desc *load_gpio;
+
+ struct drm_bridge *panel_bridge;
+ struct drm_panel *panel;
+ struct drm_bridge bridge;
+};
+
+static int hx8837_bridge_attach(struct drm_bridge *bridge,
+
Re: [RESEND PATCH v3 3/3] phy: Add USB HSIC PHY driver for Marvell MMP3 SoC
On Mon, Aug 31, 2020 at 02:28:08PM +0530, Vinod Koul wrote:
> On 18-08-20, 00:34, Lubomir Rintel wrote:
> > Add PHY driver for the HSICs found on Marvell MMP3 SoC. The driver is
> > rather straightforward -- the PHY essentially just needs to be enabled.
> >
> > Signed-off-by: Lubomir Rintel
> >
> > ---
> > Changes since v1:
> > - Explicitely cast drvdata pointer to make sparse happy
> >
> > drivers/phy/marvell/Kconfig | 12 +
> > drivers/phy/marvell/Makefile| 1 +
> > drivers/phy/marvell/phy-mmp3-hsic.c | 82 +
> > 3 files changed, 95 insertions(+)
> > create mode 100644 drivers/phy/marvell/phy-mmp3-hsic.c
> >
> > diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
> > index 8f6273c837ec3..6c96f2bf52665 100644
> > --- a/drivers/phy/marvell/Kconfig
> > +++ b/drivers/phy/marvell/Kconfig
> > @@ -116,3 +116,15 @@ config PHY_MMP3_USB
> > The PHY driver will be used by Marvell udc/ehci/otg driver.
> >
> > To compile this driver as a module, choose M here.
> > +
> > +config PHY_MMP3_HSIC
> > + tristate "Marvell MMP3 USB HSIC PHY Driver"
> > + depends on MACH_MMP3_DT || COMPILE_TEST
> > + select GENERIC_PHY
> > + help
> > + Enable this to support Marvell MMP3 USB HSIC PHY driver for
> > + Marvell MMP3 SoC. This driver will be used my the Marvell EHCI
> > + driver to initialize the interface to internal USB HSIC
> > + components on MMP3-based boards.
> > +
> > + To compile this driver as a module, choose M here.
> > diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
> > index 5a106b1549f41..7f296ef028292 100644
> > --- a/drivers/phy/marvell/Makefile
> > +++ b/drivers/phy/marvell/Makefile
> > @@ -3,6 +3,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) +=
> > phy-armada375-usb2.o
> > obj-$(CONFIG_PHY_BERLIN_SATA) += phy-berlin-sata.o
> > obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> > obj-$(CONFIG_PHY_MMP3_USB) += phy-mmp3-usb.o
> > +obj-$(CONFIG_PHY_MMP3_HSIC)+= phy-mmp3-hsic.o
> > obj-$(CONFIG_PHY_MVEBU_A3700_COMPHY) += phy-mvebu-a3700-comphy.o
> > obj-$(CONFIG_PHY_MVEBU_A3700_UTMI) += phy-mvebu-a3700-utmi.o
> > obj-$(CONFIG_PHY_MVEBU_A38X_COMPHY)+= phy-armada38x-comphy.o
> > diff --git a/drivers/phy/marvell/phy-mmp3-hsic.c
> > b/drivers/phy/marvell/phy-mmp3-hsic.c
> > new file mode 100644
> > index 0..47c1e8894939f
> > --- /dev/null
> > +++ b/drivers/phy/marvell/phy-mmp3-hsic.c
> > @@ -0,0 +1,82 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2020 Lubomir Rintel
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define HSIC_CTRL 0x08
> > +#define HSIC_ENABLEBIT(7)
> > +#define PLL_BYPASS BIT(4)
> > +
> > +static int mmp3_hsic_phy_init(struct phy *phy)
> > +{
> > + void __iomem *base = (void __iomem *)phy_get_drvdata(phy);
>
> you are casting away from void * and casting to another void *,
> something doesn't look correct!
This is to make it explicit to sparse that the destination type is
supposed to have the __iomem annotation. Otherwise it complains:
drivers/phy/marvell/phy-mmp3-hsic.c:61:31: warning: cast removes address
space '__iomem' of expression
> > + u32 hsic_ctrl;
> > +
> > + hsic_ctrl = readl_relaxed(base + HSIC_CTRL);
> > + hsic_ctrl |= HSIC_ENABLE;
> > + hsic_ctrl |= PLL_BYPASS;
> > + writel_relaxed(hsic_ctrl, base + HSIC_CTRL);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct phy_ops mmp3_hsic_phy_ops = {
> > + .init = mmp3_hsic_phy_init,
> > + .owner = THIS_MODULE,
> > +};
> > +
> > +static const struct of_device_id mmp3_hsic_phy_of_match[] = {
> > + { .compatible = "marvell,mmp3-hsic-phy", },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(of, mmp3_hsic_phy_of_match);
> > +
> > +static int mmp3_hsic_phy_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = >dev;
> > + struct phy_provider *provider;
> > + struct resource *resource;
> > + void __iomem *base;
> > + struct phy *phy;
> > +
> > + resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + base = devm_ioremap_resource(dev, resource);
> > + if (IS_ERR(base)) {
> > +
Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500
Hello, On Sun, Aug 23, 2020 at 10:31:36PM +0300, Dmitry Osipenko wrote: > 23.08.2020 21:20, Lubomir Rintel пишет: > > On Sun, Aug 23, 2020 at 05:08:44PM +0300, Dmitry Osipenko wrote: > >> The ENE KB930 hardware is compatible with KB3930. > >> > >> Acer A500 Iconia Tab is Android tablet device, it has KB930 controller > >> that is running firmware specifically customized for the needs of the > >> Acer A500 hardware. This means that firmware interface isn't re-usable > >> by other non-Acer devices. Some akin models of Acer tablets should be > >> able to re-use the FW interface of A500 model, like A200 for example. > >> > >> This patch adds the new compatibles to the binding. > > > > I've responded to patch 5/6 with what should've been said here [1]. > > Sorry for the confusion. > > > > In any case please consider adding a new binding file instead of > > modifying the kb3930 binding doc. It would also remove a dependency on > > my patch set which should have slipped out of maintainers' radar. > > > > [1] https://lore.kernel.org/lkml/20200823180041.GB209852@demiurge.local/ > > Hello, Lubomir! I was doing some research about the differences of > KB3930 and KB930 before created this patch and my understanding is that > the controllers are mostly identical. I've seen posts from people who > replaced KB3930 with KB930 (and vice versa) on various notebooks and it > worked, although not always. > > It's a very common practice to re-use binding in a case of a sibling > hardware. Do you know what are the exact differences between KB3930 and > KB930 which could justify having separate bindings? > > The firmware implementation varies a lot from device to device, It sometimes does. The ENE's downstream driver suggests there are parts that run more-or-less stock firmware that are comatible with each other. That is why I grabbed the generic kb3930 name. > and > thus, each device needs to have its own driver in order to talk to the > firmware, but hardware description (i.e. DT binding) should be common > for all devices. Note the DT is not the hardware description. It's the description of how the hardware presents itself, from the software's perspective. As far as that is concerned, the devices don't seem to have anything in common at all (other than the bus address). The fact that you need an entirely different driver implies this. This would be the case even if the A500 EC was based directly on a KB3930. A good reason to keep bindings for different yet somewhat similar devices in a single document is to avoid duplication. Yet here there's very little to share here. If you've done your bindings correctly, you'd need to conditionalize the monitored-battery and power-supplies properties for acer,a500-iconia-ec, complicating the binding too much. It makes more sense to just add a new document. Thanks, Lubo
Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500
On Sun, Aug 23, 2020 at 05:08:44PM +0300, Dmitry Osipenko wrote: > The ENE KB930 hardware is compatible with KB3930. > > Acer A500 Iconia Tab is Android tablet device, it has KB930 controller > that is running firmware specifically customized for the needs of the > Acer A500 hardware. This means that firmware interface isn't re-usable > by other non-Acer devices. Some akin models of Acer tablets should be > able to re-use the FW interface of A500 model, like A200 for example. > > This patch adds the new compatibles to the binding. I've responded to patch 5/6 with what should've been said here [1]. Sorry for the confusion. In any case please consider adding a new binding file instead of modifying the kb3930 binding doc. It would also remove a dependency on my patch set which should have slipped out of maintainers' radar. [1] https://lore.kernel.org/lkml/20200823180041.GB209852@demiurge.local/ Take care Lubo > > Signed-off-by: Dmitry Osipenko > --- > Documentation/devicetree/bindings/mfd/ene-kb3930.yaml | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > index 074243c40891..5a1c4a959d9c 100644 > --- a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > +++ b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > @@ -17,8 +17,11 @@ properties: >compatible: > items: >- enum: > +- acer,a500-iconia-ec # Acer A500 Iconia tablet device > - dell,wyse-ariel-ec # Dell Wyse Ariel board (3020) > - - const: ene,kb3930 > + - enum: > +- ene,kb3930 > +- ene,kb930 >reg: > maxItems: 1 > > -- > 2.27.0 >
Re: [PATCH v1 1/6] mfd: Add driver for Embedded Controller found on Acer Iconia Tab A500
Hello,
On Sun, Aug 23, 2020 at 05:08:41PM +0300, Dmitry Osipenko wrote:
> Acer Iconia Tab A500 is an Android tablet device, it has ENE KB930
> Embedded Controller which provides battery-gauge, LED, GPIO and some
> other functions. The EC uses firmware that is specifically customized
> for Acer A500. This patch adds MFD driver for the Embedded Controller
> which allows to power-off / reboot the A500 device, it also provides
> a common register read/write API that will be used by the sub-devices.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/mfd/Kconfig | 10 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/acer-ec-a500.c | 196 +++
> include/linux/mfd/acer-ec-a500.h | 80 +
> 4 files changed, 287 insertions(+)
> create mode 100644 drivers/mfd/acer-ec-a500.c
> create mode 100644 include/linux/mfd/acer-ec-a500.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 33df0837ab41..9e5cf88a52d8 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2062,6 +2062,16 @@ config MFD_KHADAS_MCU
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_ACER_A500_EC
> + tristate "Embedded Controller driver for Acer Iconia Tab A500"
> + depends on (I2C_TEGRA && ARCH_TEGRA_2x_SOC) || COMPILE_TEST
This seems to also depend on I2C and OF. Perhaps I2C_TEGRA and
ARCH_TEGRA_2x_SOC imply that, but it could lead to build failures with
COMPILE_TEST=y.
> + select MFD_CORE
> + help
> + Support for Acer Iconia Tab A500 Embedded Controller.
> +
> + The controller itself is ENE KB930, it is running firmware
> + customized for the specific needs of the Acer A500 hardware.
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index a60e5f835283..6e3a6162ad94 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -262,5 +262,6 @@ obj-$(CONFIG_MFD_ROHM_BD71828)+= rohm-bd71828.o
> obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
> obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
> +obj-$(CONFIG_MFD_ACER_A500_EC) += acer-ec-a500.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> diff --git a/drivers/mfd/acer-ec-a500.c b/drivers/mfd/acer-ec-a500.c
> new file mode 100644
> index ..f75bb60ab408
> --- /dev/null
> +++ b/drivers/mfd/acer-ec-a500.c
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * MFD driver for Acer Iconia Tab A500 Embedded Controller.
> + *
> + * Copyright 2020 GRATE-driver project.
> + *
> + * Based on downstream driver from Acer Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define A500_EC_I2C_ERR_TIMEOUT 500
> +
> +/* cmd delay ms */
> +A500_EC_COMMAND(SHUTDOWN,0x52, 1000);
> +A500_EC_COMMAND(WARM_REBOOT, 0x54, 1000);
> +A500_EC_COMMAND(COLD_REBOOT, 0x55, 1000);
> +
> +static struct a500_ec *a500_ec_scratch;
If this is only used for power_off, please rename it. I've been told to
do so in my driver: https://lore.kernel.org/lkml/20200519104933.GX271301@dell/
> +
> +static void a500_ec_delay(unsigned int delay_ms)
> +{
> + /* interrupts could be disabled on shutdown or reboot */
> + if (irqs_disabled())
> + mdelay(delay_ms);
> + else
> + msleep(delay_ms);
> +}
> +
> +int a500_ec_read_locked(struct a500_ec *ec_chip,
> + const struct a500_ec_cmd *cmd_desc)
Any reason you're exporting these to the cell drivers instead of using
regmap?
I think regmap would also help you with the locking if you set .lock() and
.unlock() callbacks in regmap_config.
> +{
> + struct i2c_client *client = ec_chip->client;
> + unsigned int retries = 5;
> + s32 ret = 0;
> +
> + while (retries-- > 0) {
> + ret = i2c_smbus_read_word_data(client, cmd_desc->cmd);
> + if (ret >= 0)
> + break;
> +
> + a500_ec_delay(A500_EC_I2C_ERR_TIMEOUT);
> + }
> +
> + if (ret < 0) {
> + dev_err(>dev, "i2c read command 0x%x failed: %d\n",
> + cmd_desc->cmd, ret);
> + return ret;
> + }
> +
> + a500_ec_delay(cmd_desc->post_delay);
> +
> + return le16_to_cpu(ret);
> +}
> +EXPORT_SYMBOL_GPL(a500_ec_read_locked);
> +
> +int a500_ec_write_locked(struct a500_ec *ec_chip,
> + const struct a500_ec_cmd *cmd_desc, u16 value)
> +{
> + struct i2c_client *client = ec_chip->client;
> + unsigned int retries = 5;
> + s32 ret = 0;
> +
> + while (retries-- > 0) {
> + ret = i2c_smbus_write_word_data(client, cmd_desc->cmd,
> + le16_to_cpu(value));
> + if
Re: [PATCH v1 5/6] dt-bindings: mfd: ene-kb3930: Document power-supplies and monitored-battery properties
Hi,
On Sun, Aug 23, 2020 at 05:08:45PM +0300, Dmitry Osipenko wrote:
> Battery could be connected to the controller and in this case controller
> will provide a battery-monitor function.
>
> The power-supplies phandle property is needed in order to describe the
> power supply which is used for charging of the battery, this allows to
> determine whither battery is charging or discharging, depending on the
> supply state.
>
> The monitored-battery phandle provides information about the battery cell
> characteristics.
I believe it would be better if you created a new binding document
instead of reusing this one -- the hardware part iseems to be a
different one and the firmware it runs seems to be behaving totally
differently than the usual ENE firmware [1].
[1] This eneec.c seems to be coming from ENE, so I'm assuming it's a
good enough description of how their firmware behaves:
https://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp3-dell-ariel.git/tree/drivers/input/serio/eneec.c
Cheers
Lubo
> Signed-off-by: Dmitry Osipenko
> ---
> .../devicetree/bindings/mfd/ene-kb3930.yaml| 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> index 5a1c4a959d9c..435728054f3a 100644
> --- a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> +++ b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> @@ -29,6 +29,8 @@ properties:
> description: GPIO used with the shutdown protocol on Ariel
> maxItems: 2
>
> + monitored-battery: true
> + power-supplies: true
>system-power-controller: true
>
> required:
> @@ -41,6 +43,19 @@ examples:
>- |
> #include
>
> +battery: battery-cell {
> +compatible = "simple-battery";
> +charge-full-design-microamp-hours = <326>;
> +energy-full-design-microwatt-hours = <2400>;
> +operating-range-celsius = <0 40>;
> +};
> +
> +mains: ac-adapter {
> + compatible = "gpio-charger";
> + charger-type = "mains";
> + gpios = < 125 GPIO_ACTIVE_LOW>;
> +};
> +
> i2c {
>#address-cells = <1>;
>#size-cells = <0>;
> @@ -52,6 +67,9 @@ examples:
>
> off-gpios = < 126 GPIO_ACTIVE_HIGH>,
> < 127 GPIO_ACTIVE_HIGH>;
> +
> +monitored-battery = <>;
> +power-supplies = <>;
>};
> };
>
> --
> 2.27.0
>
[PATCH v4 0/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
(Re-sending the cover letter here, because I left the subject empty and the archive didn't pick it up. Sorry.) Hi, please take a look at the patches chained to this messages and consider applying them. They add support for the controller that drives the panel on the OLPC XO laptops. Compared to the previous version the bindings have been converted to YAML and the driver itself has been rewritten without any fancy features such as the self-refresh so that the bare minimum works before the rest can be figured out. Detailed change logs are in individual patches. Tested on an OLPC XO-1.75 laptop. Thank you Lubo
Re: [PATCH 2/2] drm/panel: simple: Add Innolux N133HSE panel support
On Mon, May 11, 2020 at 09:47:08AM +0200, Sam Ravnborg wrote:
> Hi Richard.
>
> On Sat, May 09, 2020 at 01:18:34PM +0200, s...@48.io wrote:
> > From: Sean Cross
> >
> > The Innolux N133HSE panel is a 13.3" 1920x1080 panel that contains an
> > integrated backlight, and connects via eDP.
> >
> > It is used in the Kosagi Novena.
>
> Thanks for the patch.
>
>
> >
> > Signed-off-by: Sean Cross
> > Signed-off-by: Richard Marko
> > Cc: Shawn Guo
> > Cc: Fabio Estevam
> > Cc: Thierry Reding
> > To: dri-de...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/panel/panel-simple.c | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 3ad828eaefe1..c8a93771d398 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1906,6 +1906,30 @@ static const struct panel_desc innolux_n116bge = {
> > },
> > };
> >
> > +static const struct drm_display_mode innolux_n133hse_ea1_mode = {
> > + .clock = 138500,
> > + .hdisplay = 1920,
> > + .hsync_start = 1920 + 46,
> > + .hsync_end = 1920 + 46 + 30,
> > + .htotal = 1920 + 46 + 30 + 84,
> > + .vdisplay = 1080,
> > + .vsync_start = 1080 + 2,
> > + .vsync_end = 1080 + 2 + 4,
> > + .vtotal = 1080 + 2 + 4 + 26,
> > + .vrefresh = 60,
> > +};
> > +
> > +static const struct panel_desc innolux_n133hse_ea1 = {
> > + .modes = _n133hse_ea1_mode,
> > + .num_modes = 1,
> > + .bpc = 8,
> > + .size = {
> > + .width = 293,
> > + .height = 165,
> > + },
> > + .connector_type = DRM_MODE_CONNECTOR_eDP,
> Please include .bus_format and .bus_flags info too.
>
> We are relying more and more on this type of info so we need it to be
> present.
I am wondering which of the flags make sense for eDP and how the bus
format should be described?
Some eDP panels seems [1] to specify DRM_BUS_FLAG_DATA_MSB_TO_LSB and
DRM_BUS_FLAG_SYNC_DRIVE_NEGEDGE, but I am not sure what sense they make
for packet data with embedded clock that eDP uses? (Unless, of course,
my understanding of eDP is entirely missing the point.)
This panel uses RGB888 data over two differential pairs. Would
format = MEDIA_BUS_FMT_RGB888_1X24 be appropriate?
[1] N133HSE-EA1 Datasheet
http://www.vslcd.com/specification/N133HSE-EA1.pdf
> Sam
Thank you,
Lubo
[PATCH v4 1/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
Himax HX8837 is a secondary display controller used to drive the panel
on OLPC platforms.
Signed-off-by: Lubomir Rintel
---
Changes since v3:
- Moved to bindings/display/
- Added the ports
- Converted to YAML
- Removed Pavel's Ack, because the changes are substantial
Changes since v2:
- s/betweend/between/
Changes since v1:
- s/load-gpio/load-gpios/
- Use interrupt bindings instead of gpio for the IRQ
.../bindings/display/bridge/himax,hx8837.yaml | 96 +++
1 file changed, 96 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
new file mode 100644
index 0..f5b0a00f5089d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2018,2019,2020 Lubomir Rintel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/himax,hx8837.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HX8837 Display Controller Device Tree Bindings
+
+maintainers:
+ - Lubomir Rintel
+
+properties:
+ compatible:
+const: himax,hx8837
+
+ reg:
+const: 0xd
+
+ load-gpios:
+maxItems: 1
+description: GPIO specifier of DCON_LOAD pin (active high)
+
+ stat-gpios:
+minItems: 2
+description: GPIO specifier of DCON_STAT0 and DCON_STAT1 pins (active high)
+
+ interrupts:
+maxItems: 1
+description: Interrupt specifier of DCON_IRQ pin (edge falling)
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for RGB input.
+
+ port@1:
+type: object
+description: |
+ Video port connected to the panel.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - load-gpios
+ - stat-gpios
+ - interrupts
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+lcd-controller@d {
+compatible = "himax,hx8837";
+reg = <0x0d>;
+stat-gpios = < 100 GPIO_ACTIVE_HIGH>,
+ < 101 GPIO_ACTIVE_HIGH>;
+load-gpios = < 142 GPIO_ACTIVE_HIGH>;
+interrupts = < 124 IRQ_TYPE_EDGE_FALLING>;
+
+ports {
+#address-cells = <0x01>;
+#size-cells = <0x00>;
+
+port@0 {
+reg = <0x00>;
+dcon_rgb_in: endpoint {
+remote-endpoint = <_rgb_out>;
+};
+};
+
+port@1 {
+reg = <0x01>;
+dcon_gettl_out: endpoint {
+remote-endpoint = <_dettl_in>;
+};
+};
+};
+};
+};
--
2.26.2
[no subject]
Hi, please take a look at the patches chained to this messages and consider applying them. They add support for the controller that drives the panel on the OLPC XO laptops. Compared to the previous version the bindings have been converted to YAML and the driver itself has been rewritten without any fancy features such as the self-refresh so that the bare minimum works before the rest can be figured out. Detailed change logs are in individual patches. Tested on an OLPC XO-1.75 laptop. Thank you Lubo
[PATCH v4 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Himax HX8837 is used to drive the LCD panel on OLPC platforms.
It controls the panel backlight and is able to refresh it when the LCD
controller (and the rest of the plaform) is powered off.
It also converts regular RGB color data from the LCDC so that it looks
reasonable on the OLPC LCD panel with a monochromatic layer on top of a
layer that can either reflect light (b/w sunlight readable mode) or light
pattern of red, green and blue pixels.
At this point, the driver is rather basic. The self-refresh mode is not
supported. There's no way of independently controlling the color swizzling,
antialiasing or b/w conversion, but it probably isn't too useful either.
There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
DRM, so this driver doesn't replace the other one yet.
Signed-off-by: Lubomir Rintel
---
Changes since v3:
- Added this patch, in place of a driver derived from
drivers/staging/olpc_dcon. Compared to the previous one this
implements the bare minimum, without the fancy stuff such as
self-refresh that need more work/thinking.
drivers/gpu/drm/bridge/Kconfig| 13 ++
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/himax-hx8837.c | 325 ++
3 files changed, 339 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fce..df30d61c3fee1 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_HIMAX_HX8837
+tristate "HiMax HX8837 OLPC Display Controller"
+ depends on OF
+ depends on OLPC || ARCH_MMP || COMPILE_TEST
+ select DRM_KMS_HELPER
+select BACKLIGHT_LCD_SUPPORT
+select BACKLIGHT_CLASS_DEVICE
+help
+ Enable support for HiMax HX8837 Display Controller as found in the
+ OLPC XO laptops.
+
+ If your laptop doesn't have green ears, say "N"
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e43473..70d97c84382d5 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
b/drivers/gpu/drm/bridge/himax-hx8837.c
new file mode 100644
index 0..1e97fcb8ce505
--- /dev/null
+++ b/drivers/gpu/drm/bridge/himax-hx8837.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HiMax HX8837 Display Controller Driver
+ *
+ * Datasheet: http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
+ *
+ * Copyright (C) 2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define bridge_to_hx8837_priv(x) \
+ container_of(x, struct hx8837_priv, bridge)
+
+/* DCON registers */
+enum {
+ DCON_REG_ID = 0x00,
+ DCON_REG_MODE = 0x01,
+ DCON_REG_HRES = 0x02,
+ DCON_REG_HTOTAL = 0x03,
+ DCON_REG_HSYNC_WIDTH= 0x04,
+ DCON_REG_VRES = 0x05,
+ DCON_REG_VTOTAL = 0x06,
+ DCON_REG_VSYNC_WIDTH= 0x07,
+ DCON_REG_TIMEOUT= 0x08,
+ DCON_REG_SCAN_INT = 0x09,
+ DCON_REG_BRIGHT = 0x0a,
+ DCON_REG_MEM_OPT_A = 0x41,
+ DCON_REG_MEM_OPT_B = 0x42,
+};
+
+/* DCON_REG_MODE */
+enum {
+ MODE_PASSTHRU = BIT(0),
+ MODE_SLEEP = BIT(1),
+ MODE_SLEEP_AUTO = BIT(2),
+ MODE_BL_ENABLE = BIT(3),
+ MODE_BLANK = BIT(4),
+ MODE_CSWIZZLE = BIT(5),
+ MODE_COL_AA = BIT(6),
+ MODE_MONO_LUMA = BIT(7),
+ MODE_SCAN_INT = BIT(8),
+ MODE_CLOCKDIV = BIT(9),
+ MODE_DEBUG = BIT(14),
+ MODE_SELFTEST = BIT(15),
+};
+
+struct hx8837_priv {
+ struct regmap *regmap;
+ struct gpio_desc *load_gpio;
+
+ struct drm_bridge *panel_bridge;
+ struct drm_panel *panel;
+ struct drm_bridge bridge;
+};
+
+static int hx8837_bridge_attach(struct drm_bridge *bridge,
+
[PATCH 1/2] dt-bindings: display: simple: add Innolux LS075AT011
Add the Innolux LS075AT011 7.5" (1200x900) color/reflective LCD panel to the panel-simple compatible list. This panel is used in the OLPC laptops. Signed-off-by: Lubomir Rintel --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 6dd59e59f..cad63a639e258 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -153,6 +153,8 @@ properties: - innolux,g121i1-l01 # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel - innolux,g121x1-l03 +# Innolux LS075AT011 7.5" (1200x900) color/reflective LCD panel + - innolux,ls075at011 # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel - innolux,n116bge # InnoLux 15.6" WXGA TFT LCD panel -- 2.26.2
[PATCH 0/2] drm/panel: Add support for Innolux LS075AT011
Hi,
Please take a look at the patches chanied to this message and consider
applying them. They add description of the display panel found on OLPC
laptops to the simple panel driver.
There is no datasheet for the hardware and thus the timings were
determined on a best effort basis. The clock range is gotten from the
data sheet of the display controller [1] and the other timings are what
OLPC laptops actually use. The panel seems to cope with different sync
timings, but I'm not sure wherher there's any value in attempting to
figure out what range is actually permissible.
I could not figure out the right definitions for the connector and the
bus format. I'm not sure how necessary they are, but at least the
drm-panel driver insists on connector type being defined so I picked
LVDS because that seems to be used for internal laptop screens.
The signalling is not actually differential. It uses TTL levels with
data sampled on rising and falling clock edges; sort of like this (taken
from [1], P.20):
__
FSTH / \___
__
FCLK /\/\/\/\/
FD00 XXXXXXX
FD01 XXXXXXX
FD10 XXXXXXX
FD11 XXXXXXX
FD20 XXXXXXX
FD21 XXXXXXX
||||
data 1data 2 ...
(2x6bit) (2x6bit)
I believe the data just carries brightness because each pixel on the
panel has a fixed color; with the red, green and blue pixels organized
in a pattern [2]. (The HX8837 that drives the color does the conversion
from RGB).
Tested on an OLPC XO-1.75 laptop. XO-1 and XO-1.5 use the same hardware,
but their display controllers are not supported by DRM at the moment.
[1] http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
[2] http://wiki.laptop.org/go/Display
Thank you!
Lubo
[PATCH 2/2] drm/panel: simple: Add support for Innolux LS075AT011
This adds support for the Innolux LS075AT011 7.5" 1200x900 panel. There's
no public data sheet for the panel -- the values have been taken from Open
Firmware and the documentation for the display controller that drives
the panel and tested on the OLPC laptop.
Signed-off-by: Lubomir Rintel
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index cb6550d37e858..dfc69457ed2d4 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2121,6 +2121,30 @@ static const struct panel_desc innolux_g121x1_l03 = {
},
};
+static const struct display_timing innolux_ls075at011_timing = {
+ .pixelclock = { 5600, 5700, 5800 },
+ .hactive = { 1200, 1200, 1200 },
+ .hfront_porch = { 26, 26, 26 },
+ .hback_porch = { 24, 24, 24 },
+ .hsync_len = { 6, 6, 6 },
+ .vactive = { 900, 900, 900 },
+ .vfront_porch = { 4, 4, 4 },
+ .vback_porch = { 5, 5, 5 },
+ .vsync_len = { 3, 3, 3 },
+ .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
+};
+
+static const struct panel_desc innolux_ls075at011 = {
+ .timings = _ls075at011_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 115,
+ },
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
/*
* Datasheet specifies that at 60 Hz refresh rate:
* - total horizontal time: { 1506, 1592, 1716 }
@@ -3907,6 +3931,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g121x1-l03",
.data = _g121x1_l03,
+ }, {
+ .compatible = "innolux,ls075at011",
+ .data = _ls075at011,
}, {
.compatible = "innolux,n116bge",
.data = _n116bge,
--
2.26.2
