[PATCH v2 3/5] dt/bindings: qcom_nandc: Add DT bindings
Add DT bindings document for the Qualcomm NAND controller driver.
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja
---
.../devicetree/bindings/mtd/qcom_nandc.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..e24c77a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,48 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible: should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks: must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+ always on clock
+- dmas:DMA specifier, consisting of a phandle to the
ADM DMA
+ controller node and the channel number to be used for
+ NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names: must be "rxtx"
+- qcom,cmd-crci: must contain the ADM command type CRCI block instance
+ number specified for the NAND controller on the given
+ platform
+- qcom,data-crci: must contain the ADM data type CRCI block instance
+ number specified for the NAND controller on the given
+ platform
+
+Optional properties:
+- nand-bus-width: bus width. Must be 8 or 16. If not present, 8 is chosen
+ as default
+
+- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8
+ bits. If not present, 4 is chosen as default
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@0x1ac0 {
+ compatible = "qcom,ebi2-nandc";
+ reg = <0x1ac0 0x800>;
+
+ clocks = < EBI2_CLK>,
+< EBI2_AON_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <_dma 3>;
+ dma-names = "rxtx";
+ qcom,cmd-crci = <15>;
+ qcom,data-crci = <3>;
+
+ partition@0 {
+ ...
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] mtd: Qualcomm NAND controller driver
Add support for the NAND controller driver for SoC's that contain EBI2. For now, the only SoC upstream that has EBI2 is IPQ806x. The original version was posted a while back. The main comments were about the driver not being able to use nand_bbt. This was because the controller could read factory bad block markers only in RAW mode. This forced us to implement our own versions of chip->block_bad and chip->blobk_markbad, and also we had to skip creating a BBT. Discussions with Kevin Cernekee concluded that having a new BBT flag that incorporates this controller's special requirement is a possible option. The new version makes use of this flag and now uses nand_bbt, at the cost of implement read_oob_raw and write_oob_raw ops. The patchset requires the v6 ADM dmaengine patches posted by Andy: https://lkml.org/lkml/2015/3/17/19 v1: - original series: https://lkml.org/lkml/2015/1/16/317 v2: - Added a new BBT flag that allows us to read BBM in raw mode - reduce memcpy-s in the driver - some refactor and clean ups because of above changes Archit Taneja (5): mtd: nand: Create a BBT flag to access bad block markers in raw mode mtd: nand: Qualcomm NAND controller driver dt/bindings: qcom_nandc: Add DT bindings arm: qcom: dts: Add NAND controller node for ipq806x arm: qcom: dts: Enale NAND node on IPQ8064 AP148 platform .../devicetree/bindings/mtd/qcom_nandc.txt | 48 + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36 + arch/arm/boot/dts/qcom-ipq8064.dtsi| 15 + drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/nand_base.c |6 +- drivers/mtd/nand/nand_bbt.c|6 +- drivers/mtd/nand/qcom_nandc.c | 2019 include/linux/mtd/bbm.h|7 + 9 files changed, 2143 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt create mode 100644 drivers/mtd/nand/qcom_nandc.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] dt/bindings: qcom_nandc: Add DT bindings
Add DT bindings document for the Qualcomm NAND controller driver.
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
.../devicetree/bindings/mtd/qcom_nandc.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..e24c77a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,48 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible: should be qcom,ebi2-nand for IPQ806x
+- reg: MMIO address range
+- clocks: must contain core clock and always on clock
+- clock-names: must contain core for the core clock and aon for the
+ always on clock
+- dmas:DMA specifier, consisting of a phandle to the
ADM DMA
+ controller node and the channel number to be used for
+ NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names: must be rxtx
+- qcom,cmd-crci: must contain the ADM command type CRCI block instance
+ number specified for the NAND controller on the given
+ platform
+- qcom,data-crci: must contain the ADM data type CRCI block instance
+ number specified for the NAND controller on the given
+ platform
+
+Optional properties:
+- nand-bus-width: bus width. Must be 8 or 16. If not present, 8 is chosen
+ as default
+
+- nand-ecc-strength: number of bits to correct per ECC step. Must be 4 or 8
+ bits. If not present, 4 is chosen as default
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@0x1ac0 {
+ compatible = qcom,ebi2-nandc;
+ reg = 0x1ac0 0x800;
+
+ clocks = gcc EBI2_CLK,
+gcc EBI2_AON_CLK;
+ clock-names = core, aon;
+
+ dmas = adm_dma 3;
+ dma-names = rxtx;
+ qcom,cmd-crci = 15;
+ qcom,data-crci = 3;
+
+ partition@0 {
+ ...
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] mtd: Qualcomm NAND controller driver
Add support for the NAND controller driver for SoC's that contain EBI2. For now, the only SoC upstream that has EBI2 is IPQ806x. The original version was posted a while back. The main comments were about the driver not being able to use nand_bbt. This was because the controller could read factory bad block markers only in RAW mode. This forced us to implement our own versions of chip-block_bad and chip-blobk_markbad, and also we had to skip creating a BBT. Discussions with Kevin Cernekee concluded that having a new BBT flag that incorporates this controller's special requirement is a possible option. The new version makes use of this flag and now uses nand_bbt, at the cost of implement read_oob_raw and write_oob_raw ops. The patchset requires the v6 ADM dmaengine patches posted by Andy: https://lkml.org/lkml/2015/3/17/19 v1: - original series: https://lkml.org/lkml/2015/1/16/317 v2: - Added a new BBT flag that allows us to read BBM in raw mode - reduce memcpy-s in the driver - some refactor and clean ups because of above changes Archit Taneja (5): mtd: nand: Create a BBT flag to access bad block markers in raw mode mtd: nand: Qualcomm NAND controller driver dt/bindings: qcom_nandc: Add DT bindings arm: qcom: dts: Add NAND controller node for ipq806x arm: qcom: dts: Enale NAND node on IPQ8064 AP148 platform .../devicetree/bindings/mtd/qcom_nandc.txt | 48 + arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36 + arch/arm/boot/dts/qcom-ipq8064.dtsi| 15 + drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/nand_base.c |6 +- drivers/mtd/nand/nand_bbt.c|6 +- drivers/mtd/nand/qcom_nandc.c | 2019 include/linux/mtd/bbm.h|7 + 9 files changed, 2143 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt create mode 100644 drivers/mtd/nand/qcom_nandc.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] mtd: nand: Qualcomm NAND controller driver
The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx, MDM9x15 series. It exists as a sub block inside the IPs EBI2 (External Bus Interface 2) and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a broader interface for external slow peripheral devices such as LCD and NAND/NOR flash memory or SRAM like interfaces. We add support for the NAND controller found within EBI2. For the SoCs of our interest, we only use the NAND controller within EBI2. Therefore, it's safe for us to assume that the NAND controller is a standalone block within the SoC. The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and 16 bit correction/step) and RS ECC(4 bit correction/step) that covers main and spare data. The controller contains an internal 512 byte page buffer to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA for register read/write and data transfers. The controller performs page reads and writes at a codeword/step level of 512 bytes. It can support up to 2 external chips of different configurations. The driver prepares register read and write configuration descriptors for each codeword, followed by data descriptors to read or write data from the controller's internal buffer. It uses a single ADM DMA channel that we get via dmaengine API. The controller requires 2 ADM CRCIs for command and data flow control. These are passed via DT. The ecc layout used by the controller is syndrome like, but we can't use the standard syndrome ecc ops because of several reasons. First, the amount of data bytes covered by ecc isn't same in each step. Second, writing to free oob space requires us writing to the entire step in which the oob lies. This forces us to create our own ecc ops. One more difference is how the controller accesses the bad block marker. The controller ignores reading the marker when ECC is enabled. ECC needs to be explicity disabled to read or write to the bad block marker. For this reason, we use the newly created flag NAND_BBT_ACCESS_BBM_RAW to read the factory provided bad block markers. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/qcom_nandc.c | 2019 + 3 files changed, 2027 insertions(+) create mode 100644 drivers/mtd/nand/qcom_nandc.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5b2806a..31951fc 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -538,4 +538,11 @@ config MTD_NAND_HISI504 help Enables support for NAND controller on Hisilicon SoC Hip04. +config MTD_NAND_QCOM + tristate Support for NAND on QCOM SoCs + depends on ARCH_QCOM QCOM_ADM + help + Enables support for NAND flash chips on SoCs containing the EBI2 NAND + controller. This controller is found on IPQ806x SoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 1f897ec..87b6a1d 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -53,5 +53,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ +obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c new file mode 100644 index 000..51c284c --- /dev/null +++ b/drivers/mtd/nand/qcom_nandc.c @@ -0,0 +1,2019 @@ +/* + * Copyright (c) 2015, The Linux Foundation. All rights reserved. + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/clk.h +#include linux/slab.h +#include linux/interrupt.h +#include linux/bitops.h +#include linux/dma-mapping.h +#include linux/dmaengine.h +#include linux/module.h +#include linux/mtd/nand.h +#include linux/mtd/partitions.h +#include linux/of.h +#include linux/of_device.h +#include linux/of_mtd.h +#include linux/delay.h + +/* NANDc reg offsets */ +#define NAND_FLASH_CMD 0x00 +#define NAND_ADDR0 0x04 +#define NAND_ADDR1 0x08 +#define NAND_FLASH_CHIP_SELECT 0x0c +#define NAND_EXEC_CMD 0x10 +#define NAND_FLASH_STATUS 0x14 +#define NAND_BUFFER_STATUS 0x18 +#define NAND_DEV0_CFG0
[PATCH v2 4/5] arm: qcom: dts: Add NAND controller node for ipq806x
The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding
compatible string.
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 1e1b3f0..08dc2ef 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -350,5 +350,20 @@
status = disabled;
};
+ nand@0x1ac0 {
+ compatible = qcom,ebi2-nandc;
+ reg = 0x1ac0 0x800;
+
+ clocks = gcc EBI2_CLK,
+gcc EBI2_AON_CLK;
+ clock-names = core, aon;
+
+ dmas = adm_dma 3;
+ dma-names = rxtx;
+ qcom,cmd-crci = 15;
+ qcom,data-crci = 3;
+
+ status = disabled;
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] arm: qcom: dts: Enale NAND node on IPQ8064 AP148 platform
Enable the NAND controller node on the AP148 platform. Provide pinmux
information.
Cc: devicet...@vger.kernel.org
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 7f9ea50..03fd6b7 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,28 @@
bias-none;
};
};
+ nand_pins: nand_pins {
+ mux {
+ pins = gpio34, gpio35, gpio36,
+ gpio37, gpio38, gpio39,
+ gpio40, gpio41, gpio42,
+ gpio43, gpio44, gpio45,
+ gpio46, gpio47;
+ function = nand;
+ drive-strength = 10;
+ bias-disable;
+ };
+ pullups {
+ pins = gpio39;
+ bias-pull-up;
+ };
+ hold {
+ pins = gpio40, gpio41, gpio42,
+ gpio43, gpio44, gpio45,
+ gpio46, gpio47;
+ bias-bus-hold;
+ };
+ };
};
gsbi@1630 {
@@ -93,5 +115,19 @@
sata@2900 {
status = ok;
};
+
+ nand@0x1ac0 {
+ status = ok;
+
+ pinctrl-0 = nand_pins;
+ pinctrl-names = default;
+
+ nand-ecc-strength = 4;
+ nand-bus-width = 8;
+ };
};
};
+
+adm_dma {
+ status = ok;
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] mtd: nand: Create a BBT flag to access bad block markers in raw mode
Some controllers can access the factory bad block marker from OOB only
when they read it in raw mode. When ECC is enabled, these controllers
discard reading/writing bad block markers, preventing access to them
altogether.
The bbt driver assumes MTD_OPS_PLACE_OOB when scanning for bad blocks.
This results in the nand driver's ecc-read_oob() op to be called, which
works with ECC enabled.
Create a new BBT option flag that tells nand_bbt to force the mode to
MTD_OPS_RAW. This would result in the correct op being called for the
underlying nand controller driver.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/mtd/nand/nand_base.c | 6 +-
drivers/mtd/nand/nand_bbt.c | 6 +-
include/linux/mtd/bbm.h | 7 +++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ceb68ca..0a0c524 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -394,7 +394,11 @@ static int nand_default_block_markbad(struct mtd_info
*mtd, loff_t ofs)
} else {
ops.len = ops.ooblen = 1;
}
- ops.mode = MTD_OPS_PLACE_OOB;
+
+ if (unlikely(chip-bbt_options NAND_BBT_ACCESS_BBM_RAW))
+ ops.mode = MTD_OPS_RAW;
+ else
+ ops.mode = MTD_OPS_PLACE_OOB;
/* Write to first/last page(s) if necessary */
if (chip-bbt_options NAND_BBT_SCANLASTPAGE)
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 63a1a36..f2d89c9 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -420,7 +420,11 @@ static int scan_block_fast(struct mtd_info *mtd, struct
nand_bbt_descr *bd,
ops.oobbuf = buf;
ops.ooboffs = 0;
ops.datbuf = NULL;
- ops.mode = MTD_OPS_PLACE_OOB;
+
+ if (unlikely(bd-options NAND_BBT_ACCESS_BBM_RAW))
+ ops.mode = MTD_OPS_RAW;
+ else
+ ops.mode = MTD_OPS_PLACE_OOB;
for (j = 0; j numpages; j++) {
/*
diff --git a/include/linux/mtd/bbm.h b/include/linux/mtd/bbm.h
index 36bb6a5..f67f84a 100644
--- a/include/linux/mtd/bbm.h
+++ b/include/linux/mtd/bbm.h
@@ -116,6 +116,13 @@ struct nand_bbt_descr {
#define NAND_BBT_NO_OOB_BBM0x0008
/*
+ * Force MTD_OPS_RAW mode when trying to access bad block markes from OOB. To
+ * be used by controllers which can access BBM only when ECC is disabled, i.e,
+ * when in RAW access mode
+ */
+#define NAND_BBT_ACCESS_BBM_RAW0x0010
+
+/*
* Flag set by nand_create_default_bbt_descr(), marking that the nand_bbt_descr
* was allocated dynamicaly and must be freed in nand_release(). Has no meaning
* in nand_chip.bbt_options.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the drm-misc tree
Hi,
On 07/14/2015 08:22 AM, Stephen Rothwell wrote:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function
'virtio_pci_kick_out_firmware_fb':
drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of
function 'drm_fb_helper_remove_conflicting_framebuffers'
[-Werror=implicit-function-declaration]
drm_fb_helper_remove_conflicting_framebuffers(ap, "virtiodrmfb",
^
Caused by commit
7bd870e7b1c8 ("drm/virtio: Use new drm_fb_helper functions")
I have used the drm-misc tree from next-20150713 for today.
(That commit said "COMPILE TESTED ONLY" :-()
My bad. The commit messages were for a slightly older version.
I'll fix this, and the warnings in the other mail.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the drm-misc tree
Hi, On 07/14/2015 08:22 AM, Stephen Rothwell wrote: Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/gpu/drm/virtio/virtgpu_drm_bus.c: In function 'virtio_pci_kick_out_firmware_fb': drivers/gpu/drm/virtio/virtgpu_drm_bus.c:55:2: error: implicit declaration of function 'drm_fb_helper_remove_conflicting_framebuffers' [-Werror=implicit-function-declaration] drm_fb_helper_remove_conflicting_framebuffers(ap, virtiodrmfb, ^ Caused by commit 7bd870e7b1c8 (drm/virtio: Use new drm_fb_helper functions) I have used the drm-misc tree from next-20150713 for today. (That commit said COMPILE TESTED ONLY :-() My bad. The commit messages were for a slightly older version. I'll fix this, and the warnings in the other mail. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi, On 06/30/2015 02:01 PM, Benjamin Gaignard wrote: Hi, I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? I guess this won't be hard to do once we have a common fbdev emulation config option. We could consider this as a drm top level module param. I'll keep this in mind. Thanks, Archit Benjamin 2015-06-30 9:56 GMT+02:00 Archit Taneja : Hi, On 06/30/2015 12:40 PM, Daniel Vetter wrote: Any updates on this or too much distractions? I really think doing this would be awesome for the drm subsystem, instead of reinventing this wheel for each driver. I'd started on this again. I've got more free time now than before, so I should have something in a week or so. I agree it will help a lot (there are already two new drivers since we started discussing this!) Archit -Daniel On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote: On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote: Hi, On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs won't really work because struct declarations(like fb_info) also get removed. I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself, but that seemed a bit too intrusive. This is what I'm currently doing: - Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would actually benefit if we have drm fb helpers for them. They are used in exactly the same manner by all the drivers. - For the rest of the functions that are sparsely used, I was considering making very simple drm_fb_* wrapper functions. Something like: void drm_fb_helper_deferr
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 06/30/2015 12:40 PM, Daniel Vetter wrote:
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
I'd started on this again. I've got more free time now than before, so I
should have something in a week or so. I agree it will help a lot (there
are already two new drivers since we started discussing this!)
Archit
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter wrote:
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool "Enable legacy fbdev support for your modesetting driver"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was considering
making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper->fbdev)
fb_deferred_io_init(helper->fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
That's actually an option I considered, but I hoped we could do it with
less work. If this indeed works and you can create the patch that would be
awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Qualcomm Innovation Center, Inc. is a member of Code Auror
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi, On 06/30/2015 02:01 PM, Benjamin Gaignard wrote: Hi, I think that what have been done by Rob with module_param is also a good idea: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_drv.c?id=e90dfec78ec288d6c89a7b508a5c5d4ae8b7f934 Can you mix compilation flag and module param ? I guess this won't be hard to do once we have a common fbdev emulation config option. We could consider this as a drm top level module param. I'll keep this in mind. Thanks, Archit Benjamin 2015-06-30 9:56 GMT+02:00 Archit Taneja arch...@codeaurora.org: Hi, On 06/30/2015 12:40 PM, Daniel Vetter wrote: Any updates on this or too much distractions? I really think doing this would be awesome for the drm subsystem, instead of reinventing this wheel for each driver. I'd started on this again. I've got more free time now than before, so I should have something in a week or so. I agree it will help a lot (there are already two new drivers since we started discussing this!) Archit -Daniel On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote: Hi, On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include linux/fb.h #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs won't really work because struct declarations(like fb_info) also get removed. I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself, but that seemed a bit too intrusive. This is what I'm currently doing: - Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would actually benefit if we have drm fb helpers for them. They are used in exactly the same manner by all the drivers. - For the rest of the functions that are sparsely used, I was considering making very simple drm_fb_* wrapper functions
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 06/30/2015 12:40 PM, Daniel Vetter wrote:
Any updates on this or too much distractions? I really think doing
this would be awesome for the drm subsystem, instead of reinventing
this wheel for each driver.
I'd started on this again. I've got more free time now than before, so I
should have something in a week or so. I agree it will help a lot (there
are already two new drivers since we started discussing this!)
Archit
-Daniel
On Wed, Mar 25, 2015 at 10:21 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Mar 25, 2015 at 01:47:54PM +0530, Archit Taneja wrote:
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include linux/fb.h
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h itself,
but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap would
actually benefit if we have drm fb helpers for them. They are used in
exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was considering
making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper-fbdev)
fb_deferred_io_init(helper-fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
That's actually an option I considered, but I hoped we could do it with
less work. If this indeed works and you can create the patch that would be
awesome.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Qualcomm Innovation Center, Inc. is a member of Code
[RFC 2/2] drm/dsi: Get DSI host by DT device node
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
Non-dsi drivers that create a dummy dsi device don't have this data.
In order to get this information, they require to a phandle to the dsi
host in the device tree.
Maintain a list of all the hosts DSI that are currently registered.
This list will be used to find the mipi_dsi_host corresponding to the
device_node passed in of_find_mipi_dsi_host_by_node.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 30 ++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 9bfe215..81ddb73 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -239,6 +239,28 @@ struct mipi_dsi_device *mipi_dsi_new_dummy(struct
mipi_dsi_host *host, u32 reg)
return dsi;
}
+static DEFINE_MUTEX(host_lock);
+static LIST_HEAD(host_list);
+
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node)
+{
+ struct mipi_dsi_host *host;
+
+ mutex_lock(_lock);
+
+ list_for_each_entry(host, _list, list) {
+ if (host->dev->of_node == node) {
+ mutex_unlock(_lock);
+ return host;
+ }
+ }
+
+ mutex_unlock(_lock);
+
+ return NULL;
+}
+EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
+
int mipi_dsi_host_register(struct mipi_dsi_host *host)
{
struct device_node *node;
@@ -250,6 +272,10 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
of_mipi_dsi_device_add(host, node);
}
+ mutex_lock(_lock);
+ list_add_tail(>list, _list);
+ mutex_unlock(_lock);
+
return 0;
}
EXPORT_SYMBOL(mipi_dsi_host_register);
@@ -266,6 +292,10 @@ static int mipi_dsi_remove_device_fn(struct device *dev,
void *priv)
void mipi_dsi_host_unregister(struct mipi_dsi_host *host)
{
device_for_each_child(host->dev, NULL, mipi_dsi_remove_device_fn);
+
+ mutex_lock(_lock);
+ list_del_init(>list);
+ mutex_unlock(_lock);
}
EXPORT_SYMBOL(mipi_dsi_host_unregister);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index d06ba99..1684a0e 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -100,10 +100,12 @@ struct mipi_dsi_host_ops {
struct mipi_dsi_host {
struct device *dev;
const struct mipi_dsi_host_ops *ops;
+ struct list_head list;
};
int mipi_dsi_host_register(struct mipi_dsi_host *host);
void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node);
/* DSI mode flags */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/2] drm/dsi: Create dummy DSI devices
We can have devices where the data bus is MIPI DSI, but the control bus
is something else (i2c, spi etc). A typical example is i2c controlled
encoder bridge chips.
Such devices too require passing DSI specific parameters (number of data
lanes, DSI mode flags, color format etc) to their DSI host. For a device
that isn't 'mipi_dsi_device', there is no way of passing such parameters.
Provide the option of creating a dummy DSI device. The main purpose of
this would be to attach to a DSI host by calling mipi_dsi_attach, and
pass DSI params.
Create mipi_dsi_new_dummy for creating a dummy dsi device. The driver
calling this needs to be aware of the mipi_dsi_host it wants to attach
to, and also the DSI virtual channel the DSI device intends to use.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 78 --
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 2d5ca8ee..9bfe215 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -47,7 +47,14 @@
static int mipi_dsi_device_match(struct device *dev, struct device_driver *drv)
{
- return of_driver_match_device(dev, drv);
+ if (of_driver_match_device(dev, drv))
+ return 1;
+
+ if (!strcmp(drv->name, "mipi_dsi_dummy") &&
+ strstr(dev_name(dev), "dummy_dev"))
+ return 1;
+
+ return 0;
}
static const struct dev_pm_ops mipi_dsi_device_pm_ops = {
@@ -171,6 +178,67 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct
device_node *node)
return dsi;
}
+static int dummy_probe(struct mipi_dsi_device *dsi)
+{
+ return 0;
+}
+
+static int dummy_remove(struct mipi_dsi_device *dsi)
+{
+ return 0;
+}
+
+static void dummy_shutdown(struct mipi_dsi_device *dsi)
+{
+}
+
+static struct mipi_dsi_driver dummy_dsi_driver = {
+ .probe = dummy_probe,
+ .remove = dummy_remove,
+ .shutdown = dummy_shutdown,
+ .driver.name = "mipi_dsi_dummy",
+};
+
+static int mipi_dsi_device_add_dummy(struct mipi_dsi_device *dsi)
+{
+ struct mipi_dsi_host *host = dsi->host;
+
+ dev_set_name(>dev, "%s.dummy_dev.%d", dev_name(host->dev),
+ dsi->channel);
+
+ return device_add(>dev);
+}
+
+struct mipi_dsi_device *mipi_dsi_new_dummy(struct mipi_dsi_host *host, u32 reg)
+{
+ struct mipi_dsi_device *dsi;
+ struct device *dev = host->dev;
+ int ret;
+
+ if (reg > 3) {
+ dev_err(dev, "invalid reg property %u\n", reg);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dsi = mipi_dsi_device_alloc(host);
+ if (IS_ERR(dsi)) {
+ dev_err(dev, "failed to allocate dummy DSI device %ld\n",
+ PTR_ERR(dsi));
+ return dsi;
+ }
+
+ dsi->channel = reg;
+
+ ret = mipi_dsi_device_add_dummy(dsi);
+ if (ret) {
+ dev_err(dev, "failed to add dummy DSI device %d\n", ret);
+ kfree(dsi);
+ return ERR_PTR(ret);
+ }
+
+ return dsi;
+}
+
int mipi_dsi_host_register(struct mipi_dsi_host *host)
{
struct device_node *node;
@@ -924,7 +992,13 @@ EXPORT_SYMBOL(mipi_dsi_driver_unregister);
static int __init mipi_dsi_bus_init(void)
{
- return bus_register(_dsi_bus_type);
+ int ret;
+
+ ret = bus_register(_dsi_bus_type);
+ if (ret < 0)
+ return ret;
+
+ return mipi_dsi_driver_register(_dsi_driver);
}
postcore_initcall(mipi_dsi_bus_init);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..d06ba99 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -174,6 +174,8 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi,
const void *payload,
ssize_t mipi_dsi_generic_read(struct mipi_dsi_device *dsi, const void *params,
size_t num_params, void *data, size_t size);
+struct mipi_dsi_device *mipi_dsi_new_dummy(struct mipi_dsi_host *host, u32
reg);
+
/**
* enum mipi_dsi_dcs_tear_mode - Tearing Effect Output Line mode
* @MIPI_DSI_DCS_TEAR_MODE_VBLANK: the TE output line consists of V-Blanking
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/2] drm/dsi: DSI for devices with different control bus
We are currently restricted when it comes to supporting DSI on devices that have a non-DSI control bus. For example, DSI encoder chips are available in the market that are configured via i2c. Configuring their registers via DSI bus is either optional or not available at all. These devices still need to pass DSI parameters (data lanes, mode flags etc) to the DSI host they are connected to. We don't have a way to do that at the moment. The method presented in these patches is to provide an API to create a 'dummy' mipi_dsi_device. This device is populated with the desired DSI params, which are passed on to the host via mipi_dsi_attach(). This method will require the device driver to get a phandle to the DSI host since there is no parent-child relation between the two. Is there a better way to do this? Please let me know! Archit Taneja (2): drm/dsi: Create dummy DSI devices drm/dsi: Get DSI host by DT device node drivers/gpu/drm/drm_mipi_dsi.c | 108 - include/drm/drm_mipi_dsi.h | 4 ++ 2 files changed, 110 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/2] drm/dsi: Create dummy DSI devices
We can have devices where the data bus is MIPI DSI, but the control bus
is something else (i2c, spi etc). A typical example is i2c controlled
encoder bridge chips.
Such devices too require passing DSI specific parameters (number of data
lanes, DSI mode flags, color format etc) to their DSI host. For a device
that isn't 'mipi_dsi_device', there is no way of passing such parameters.
Provide the option of creating a dummy DSI device. The main purpose of
this would be to attach to a DSI host by calling mipi_dsi_attach, and
pass DSI params.
Create mipi_dsi_new_dummy for creating a dummy dsi device. The driver
calling this needs to be aware of the mipi_dsi_host it wants to attach
to, and also the DSI virtual channel the DSI device intends to use.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/drm_mipi_dsi.c | 78 --
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 2d5ca8ee..9bfe215 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -47,7 +47,14 @@
static int mipi_dsi_device_match(struct device *dev, struct device_driver *drv)
{
- return of_driver_match_device(dev, drv);
+ if (of_driver_match_device(dev, drv))
+ return 1;
+
+ if (!strcmp(drv-name, mipi_dsi_dummy)
+ strstr(dev_name(dev), dummy_dev))
+ return 1;
+
+ return 0;
}
static const struct dev_pm_ops mipi_dsi_device_pm_ops = {
@@ -171,6 +178,67 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct
device_node *node)
return dsi;
}
+static int dummy_probe(struct mipi_dsi_device *dsi)
+{
+ return 0;
+}
+
+static int dummy_remove(struct mipi_dsi_device *dsi)
+{
+ return 0;
+}
+
+static void dummy_shutdown(struct mipi_dsi_device *dsi)
+{
+}
+
+static struct mipi_dsi_driver dummy_dsi_driver = {
+ .probe = dummy_probe,
+ .remove = dummy_remove,
+ .shutdown = dummy_shutdown,
+ .driver.name = mipi_dsi_dummy,
+};
+
+static int mipi_dsi_device_add_dummy(struct mipi_dsi_device *dsi)
+{
+ struct mipi_dsi_host *host = dsi-host;
+
+ dev_set_name(dsi-dev, %s.dummy_dev.%d, dev_name(host-dev),
+ dsi-channel);
+
+ return device_add(dsi-dev);
+}
+
+struct mipi_dsi_device *mipi_dsi_new_dummy(struct mipi_dsi_host *host, u32 reg)
+{
+ struct mipi_dsi_device *dsi;
+ struct device *dev = host-dev;
+ int ret;
+
+ if (reg 3) {
+ dev_err(dev, invalid reg property %u\n, reg);
+ return ERR_PTR(-EINVAL);
+ }
+
+ dsi = mipi_dsi_device_alloc(host);
+ if (IS_ERR(dsi)) {
+ dev_err(dev, failed to allocate dummy DSI device %ld\n,
+ PTR_ERR(dsi));
+ return dsi;
+ }
+
+ dsi-channel = reg;
+
+ ret = mipi_dsi_device_add_dummy(dsi);
+ if (ret) {
+ dev_err(dev, failed to add dummy DSI device %d\n, ret);
+ kfree(dsi);
+ return ERR_PTR(ret);
+ }
+
+ return dsi;
+}
+
int mipi_dsi_host_register(struct mipi_dsi_host *host)
{
struct device_node *node;
@@ -924,7 +992,13 @@ EXPORT_SYMBOL(mipi_dsi_driver_unregister);
static int __init mipi_dsi_bus_init(void)
{
- return bus_register(mipi_dsi_bus_type);
+ int ret;
+
+ ret = bus_register(mipi_dsi_bus_type);
+ if (ret 0)
+ return ret;
+
+ return mipi_dsi_driver_register(dummy_dsi_driver);
}
postcore_initcall(mipi_dsi_bus_init);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..d06ba99 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -174,6 +174,8 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi,
const void *payload,
ssize_t mipi_dsi_generic_read(struct mipi_dsi_device *dsi, const void *params,
size_t num_params, void *data, size_t size);
+struct mipi_dsi_device *mipi_dsi_new_dummy(struct mipi_dsi_host *host, u32
reg);
+
/**
* enum mipi_dsi_dcs_tear_mode - Tearing Effect Output Line mode
* @MIPI_DSI_DCS_TEAR_MODE_VBLANK: the TE output line consists of V-Blanking
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/2] drm/dsi: Get DSI host by DT device node
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
Non-dsi drivers that create a dummy dsi device don't have this data.
In order to get this information, they require to a phandle to the dsi
host in the device tree.
Maintain a list of all the hosts DSI that are currently registered.
This list will be used to find the mipi_dsi_host corresponding to the
device_node passed in of_find_mipi_dsi_host_by_node.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/drm_mipi_dsi.c | 30 ++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 9bfe215..81ddb73 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -239,6 +239,28 @@ struct mipi_dsi_device *mipi_dsi_new_dummy(struct
mipi_dsi_host *host, u32 reg)
return dsi;
}
+static DEFINE_MUTEX(host_lock);
+static LIST_HEAD(host_list);
+
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node)
+{
+ struct mipi_dsi_host *host;
+
+ mutex_lock(host_lock);
+
+ list_for_each_entry(host, host_list, list) {
+ if (host-dev-of_node == node) {
+ mutex_unlock(host_lock);
+ return host;
+ }
+ }
+
+ mutex_unlock(host_lock);
+
+ return NULL;
+}
+EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
+
int mipi_dsi_host_register(struct mipi_dsi_host *host)
{
struct device_node *node;
@@ -250,6 +272,10 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
of_mipi_dsi_device_add(host, node);
}
+ mutex_lock(host_lock);
+ list_add_tail(host-list, host_list);
+ mutex_unlock(host_lock);
+
return 0;
}
EXPORT_SYMBOL(mipi_dsi_host_register);
@@ -266,6 +292,10 @@ static int mipi_dsi_remove_device_fn(struct device *dev,
void *priv)
void mipi_dsi_host_unregister(struct mipi_dsi_host *host)
{
device_for_each_child(host-dev, NULL, mipi_dsi_remove_device_fn);
+
+ mutex_lock(host_lock);
+ list_del_init(host-list);
+ mutex_unlock(host_lock);
}
EXPORT_SYMBOL(mipi_dsi_host_unregister);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index d06ba99..1684a0e 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -100,10 +100,12 @@ struct mipi_dsi_host_ops {
struct mipi_dsi_host {
struct device *dev;
const struct mipi_dsi_host_ops *ops;
+ struct list_head list;
};
int mipi_dsi_host_register(struct mipi_dsi_host *host);
void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node);
/* DSI mode flags */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/2] drm/dsi: DSI for devices with different control bus
We are currently restricted when it comes to supporting DSI on devices that have a non-DSI control bus. For example, DSI encoder chips are available in the market that are configured via i2c. Configuring their registers via DSI bus is either optional or not available at all. These devices still need to pass DSI parameters (data lanes, mode flags etc) to the DSI host they are connected to. We don't have a way to do that at the moment. The method presented in these patches is to provide an API to create a 'dummy' mipi_dsi_device. This device is populated with the desired DSI params, which are passed on to the host via mipi_dsi_attach(). This method will require the device driver to get a phandle to the DSI host since there is no parent-child relation between the two. Is there a better way to do this? Please let me know! Archit Taneja (2): drm/dsi: Create dummy DSI devices drm/dsi: Get DSI host by DT device node drivers/gpu/drm/drm_mipi_dsi.c | 108 - include/drm/drm_mipi_dsi.h | 4 ++ 2 files changed, 110 insertions(+), 2 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: qcom: Use parent rate when set rate to pixel RCG clock
On 06/26/2015 04:05 AM, Hai Li wrote:
Since the parent rate has been recalculated, pixel RCG clock
should rely on it to find the correct M/N values during set_rate,
instead of calling __clk_round_rate() to its parent again.
Tested-by: Archit Taneja
Signed-off-by: Hai Li
---
drivers/clk/qcom/clk-rcg2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 4d3e2f7..b344899 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -615,10 +615,11 @@ static int clk_pixel_set_rate(struct clk_hw *hw, unsigned
long rate,
if (!parent)
return -EINVAL;
+ src_rate = parent_rate;
+
for (; frac->num; frac++) {
request = (rate * frac->den) / frac->num;
- src_rate = __clk_round_rate(parent, request);
if ((src_rate < (request - delta)) ||
(src_rate > (request + delta)))
continue;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: qcom: Use parent rate when set rate to pixel RCG clock
On 06/26/2015 04:05 AM, Hai Li wrote:
Since the parent rate has been recalculated, pixel RCG clock
should rely on it to find the correct M/N values during set_rate,
instead of calling __clk_round_rate() to its parent again.
Tested-by: Archit Taneja arch...@codeaurora.org
Signed-off-by: Hai Li h...@codeaurora.org
---
drivers/clk/qcom/clk-rcg2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 4d3e2f7..b344899 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -615,10 +615,11 @@ static int clk_pixel_set_rate(struct clk_hw *hw, unsigned
long rate,
if (!parent)
return -EINVAL;
+ src_rate = parent_rate;
+
for (; frac-num; frac++) {
request = (rate * frac-den) / frac-num;
- src_rate = __clk_round_rate(parent, request);
if ((src_rate (request - delta)) ||
(src_rate (request + delta)))
continue;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] drm/msm: dsi host: add missing of_node_put()
On 06/22/2015 09:30 PM, Srinivas Kandagatla wrote:
On 22/06/15 15:54, Archit Taneja wrote:
Decrement device node refcount if of_get_child_by_name is successfully
called.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index de04009..1751659 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1582,6 +1582,8 @@ int msm_dsi_host_register(struct mipi_dsi_host
*host, bool check_defer)
node = of_get_child_by_name(msm_host->pdev->dev.of_node,
"panel");
if (node) {
+of_node_put(node);
+
Atleast from the current state of code, It looks like the driver is
going to refer to the node of_node_put?, So I think this is not the
right place to have of_node_put.
That's right. I made the same mistake in the later patches too. I'll fix
these.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drm/msm: dsi host: Use device graph parsing to parse connected panel
The dsi host looks for the connected panel node by parsing for a child
named 'panel'. This hierarchy isn't very flexible. The connected
panel is forced to be a child to the dsi host, and hence, a mipi dsi
device. This isn't suitable for dsi devices that don't use mipi dsi
as their control bus.
Follow the of_graph approach of creating ports and endpoints to
represent the connections between the dsi host and the panel connected
to it. In our case, the dsi host will only have one output port, linked
to the panel's input port.
Update DT binding documentation with device graph usage info.
Signed-off-by: Archit Taneja
---
Documentation/devicetree/bindings/drm/msm/dsi.txt | 15 ++
drivers/gpu/drm/msm/dsi/dsi_host.c| 64 +--
2 files changed, 63 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
index 6ccd860..c88ec3c 100644
--- a/Documentation/devicetree/bindings/drm/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -25,6 +25,9 @@ Required properties:
- vddio-supply: phandle to vdd-io regulator device node
- vdda-supply: phandle to vdda regulator device node
- qcom,dsi-phy: phandle to DSI PHY device node
+- port: DSI controller output port. This contains one endpoint subnode, with
its
+ remote-endpoint set to the phandle of the connected panel's endpoint.
+ See Documentation/devicetree/bindings/graph.txt for device graph info.
Optional properties:
- panel@0: Node of panel connected to this DSI controller.
@@ -101,6 +104,18 @@ Example:
power-supply = <...>;
backlight = <...>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+ };
+
+ port {
+ dsi0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
};
};
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1751659..ab0b23b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1379,7 +1380,7 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
msm_host->format = dsi->format;
msm_host->mode_flags = dsi->mode_flags;
- msm_host->panel_node = dsi->dev.of_node;
+ WARN_ON(dsi->dev.of_node != msm_host->panel_node);
/* Some gpios defined in panel DT need to be controlled by host */
ret = dsi_host_init_panel_gpios(msm_host, >dev);
@@ -1429,6 +1430,46 @@ static struct mipi_dsi_host_ops dsi_host_ops = {
.transfer = dsi_host_transfer,
};
+static int msm_dsi_host_parse_dt(struct msm_dsi_host *msm_host)
+{
+ struct device *dev = _host->pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *endpoint, *panel_node;
+ int ret;
+
+ ret = of_property_read_u32(np, "qcom,dsi-host-index", _host->id);
+ if (ret) {
+ dev_err(dev, "%s: host index not specified, ret=%d\n",
+ __func__, ret);
+ return ret;
+ }
+
+ /*
+* get the first endpoint node. in our case, dsi has one output port
+* to which the panel is connected.
+*/
+ endpoint = of_graph_get_next_endpoint(np, NULL);
+ if (IS_ERR(endpoint)) {
+ dev_err(dev, "%s: no valid endpoint\n", __func__);
+ return PTR_ERR(endpoint);
+ }
+
+ of_node_put(endpoint);
+
+ /* get panel node from the output port's endpoint data */
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (IS_ERR(panel_node)) {
+ dev_err(dev, "%s: no valid device\n", __func__);
+ return PTR_ERR(panel_node);
+ }
+
+ of_node_put(panel_node);
+
+ msm_host->panel_node = panel_node;
+
+ return 0;
+}
+
int msm_dsi_host_init(struct msm_dsi *msm_dsi)
{
struct msm_dsi_host *msm_host = NULL;
@@ -1443,15 +1484,13 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
- ret = of_property_read_u32(pdev->dev.of_node,
- "qcom,dsi-host-index", _host->id);
+ msm_host->pdev = pdev;
+
+ ret = msm_dsi_host_parse_dt(msm_host);
if (ret) {
- dev_err(>dev,
- "%s: host index not specified, ret=%d\n",
- __func__, ret);
+ pr_err("%s: failed to parse dt\n", __func__);
[PATCH 3/3] drm/msm: mdp4 lvds: get panel node via of graph parsing
We currently get the output connected to LVDS by looking for a phandle
called 'qcom,lvds-panel' under the mdp DT node.
Use the more standard of_graph approach to create an lvds output port,
and retrieve the panel node from the port's endpoint data.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 32 +++-
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 531e4ac..cf72eda 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -241,22 +241,36 @@ int mdp4_enable(struct mdp4_kms *mdp4_kms)
}
#ifdef CONFIG_OF
-static struct drm_panel *detect_panel(struct drm_device *dev, const char *name)
+static struct drm_panel *detect_panel(struct drm_device *dev)
{
- struct device_node *n;
+ struct device_node *endpoint, *panel_node;
+ struct device_node *np = dev->dev->of_node;
struct drm_panel *panel = NULL;
- n = of_parse_phandle(dev->dev->of_node, name, 0);
- if (n) {
- panel = of_drm_find_panel(n);
- if (!panel)
- panel = ERR_PTR(-EPROBE_DEFER);
+ endpoint = of_graph_get_next_endpoint(np, NULL);
+ if (IS_ERR(endpoint)) {
+ dev_err(dev->dev, "no valid endpoint\n");
+ return ERR_CAST(endpoint);
}
+ of_node_put(endpoint);
+
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (IS_ERR(panel_node)) {
+ dev_err(dev->dev, "no valid panel node\n");
+ return ERR_CAST(panel_node);
+ }
+
+ of_node_put(panel_node);
+
+ panel = of_drm_find_panel(panel_node);
+ if (IS_ERR(panel))
+ panel = ERR_PTR(-EPROBE_DEFER);
+
return panel;
}
#else
-static struct drm_panel *detect_panel(struct drm_device *dev, const char *name)
+static struct drm_panel *detect_panel(struct drm_device *dev)
{
// ??? maybe use a module param to specify which panel is attached?
}
@@ -294,7 +308,7 @@ static int modeset_init(struct mdp4_kms *mdp4_kms)
* Setup the LCDC/LVDS path: RGB2 -> DMA_P -> LCDC -> LVDS:
*/
- panel = detect_panel(dev, "qcom,lvds-panel");
+ panel = detect_panel(dev);
if (IS_ERR(panel)) {
ret = PTR_ERR(panel);
dev_err(dev->dev, "failed to detect LVDS panel: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index e7c5ea1..0cbeb1d 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#ifndef CONFIG_OF
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] drm/msm: dsi host: add missing of_node_put()
Decrement device node refcount if of_get_child_by_name is successfully
called.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index de04009..1751659 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1582,6 +1582,8 @@ int msm_dsi_host_register(struct mipi_dsi_host *host,
bool check_defer)
node = of_get_child_by_name(msm_host->pdev->dev.of_node,
"panel");
if (node) {
+ of_node_put(node);
+
if (!of_drm_find_panel(node))
return -EPROBE_DEFER;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] drm/msm: Use device graph to parse connected panels
drm/msm currently relies on phandles/child nodes to get data about connected panels to LVDS and DSI. This method has known limitations. Use device graphs in DT to represent the connections between the encoder outputs and the panels. Use of_graph helpers in the driver to get the panel device node. The usage of device graphs should also simplify management in dual dsi mode. I haven't tried this out yet, though. Archit Taneja (3): drm/msm: dsi host: add missing of_node_put() drm/msm: dsi host: Use device graph parsing to parse connected panel drm/msm: mdp4 lvds: get panel node via of graph parsing Documentation/devicetree/bindings/drm/msm/dsi.txt | 15 ++ drivers/gpu/drm/msm/dsi/dsi_host.c| 62 ++- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 32 drivers/gpu/drm/msm/msm_drv.h | 1 + 4 files changed, 87 insertions(+), 23 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/msm/mdp5: release SMB(shared memory blocks) in various cases
On 06/19/2015 11:33 PM, Wentao Xu wrote:
Release all blocks after the pipe is disabled, even when vsync
didn't happen in some error cases. Allow requesting SMB multiple
times before configuring to hardware, by releasing blocks not
programmed to hardware yet for shrinking case.
Tested-by: Archit Taneja
Signed-off-by: Wentao Xu
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 13 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 2 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 33 +---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 87 ++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h | 1 +
5 files changed, 104 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 97226a1..db49ee8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -78,7 +78,20 @@ static void mdp5_prepare_commit(struct msm_kms *kms, struct
drm_atomic_state *st
static void mdp5_complete_commit(struct msm_kms *kms, struct drm_atomic_state
*state)
{
+ int i;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+ int nplanes = mdp5_kms->dev->mode_config.num_total_plane;
+
+ for (i = 0; i < nplanes; i++) {
+ struct drm_plane *plane = state->planes[i];
+ struct drm_plane_state *plane_state = state->plane_states[i];
+
+ if (!plane)
+ continue;
+
+ mdp5_plane_complete_commit(plane, plane_state);
+ }
+
mdp5_disable(mdp5_kms);
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 2c0de17..42f270b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -227,6 +227,8 @@ void mdp5_plane_install_properties(struct drm_plane *plane,
struct drm_mode_object *obj);
uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
void mdp5_plane_complete_flip(struct drm_plane *plane);
+void mdp5_plane_complete_commit(struct drm_plane *plane,
+ struct drm_plane_state *state);
enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 18a3d20..05b2634 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -31,8 +31,6 @@ struct mdp5_plane {
uint32_t nformats;
uint32_t formats[32];
-
- bool enabled;
};
#define to_mdp5_plane(x) container_of(x, struct mdp5_plane, base)
@@ -56,22 +54,6 @@ static bool plane_enabled(struct drm_plane_state *state)
return state->fb && state->crtc;
}
-static int mdp5_plane_disable(struct drm_plane *plane)
-{
- struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
- struct mdp5_kms *mdp5_kms = get_kms(plane);
- enum mdp5_pipe pipe = mdp5_plane->pipe;
-
- DBG("%s: disable", mdp5_plane->name);
-
- if (mdp5_kms) {
- /* Release the memory we requested earlier from the SMP: */
- mdp5_smp_release(mdp5_kms->smp, pipe);
- }
-
- return 0;
-}
-
static void mdp5_plane_destroy(struct drm_plane *plane)
{
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
@@ -224,7 +206,6 @@ static void mdp5_plane_atomic_update(struct drm_plane
*plane,
if (!plane_enabled(state)) {
to_mdp5_plane_state(state)->pending = true;
- mdp5_plane_disable(plane);
} else if (to_mdp5_plane_state(state)->mode_changed) {
int ret;
to_mdp5_plane_state(state)->pending = true;
@@ -602,6 +583,20 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
return mdp5_plane->flush_mask;
}
+/* called after vsync in thread context */
+void mdp5_plane_complete_commit(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct mdp5_kms *mdp5_kms = get_kms(plane);
+ struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
+ enum mdp5_pipe pipe = mdp5_plane->pipe;
+
+ if (!plane_enabled(plane->state)) {
+ DBG("%s: free SMP", mdp5_plane->name);
+ mdp5_smp_release(mdp5_kms->smp, pipe);
+ }
+}
+
/* initialize plane */
struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
index 16702ae..64a27d8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
@@ -34,22 +34,44 @@
* and CANNOT be re-allocated (eg: MMB0 and M
[PATCH 0/3] drm/msm: Use device graph to parse connected panels
drm/msm currently relies on phandles/child nodes to get data about connected panels to LVDS and DSI. This method has known limitations. Use device graphs in DT to represent the connections between the encoder outputs and the panels. Use of_graph helpers in the driver to get the panel device node. The usage of device graphs should also simplify management in dual dsi mode. I haven't tried this out yet, though. Archit Taneja (3): drm/msm: dsi host: add missing of_node_put() drm/msm: dsi host: Use device graph parsing to parse connected panel drm/msm: mdp4 lvds: get panel node via of graph parsing Documentation/devicetree/bindings/drm/msm/dsi.txt | 15 ++ drivers/gpu/drm/msm/dsi/dsi_host.c| 62 ++- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 32 drivers/gpu/drm/msm/msm_drv.h | 1 + 4 files changed, 87 insertions(+), 23 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] drm/msm: mdp4 lvds: get panel node via of graph parsing
We currently get the output connected to LVDS by looking for a phandle
called 'qcom,lvds-panel' under the mdp DT node.
Use the more standard of_graph approach to create an lvds output port,
and retrieve the panel node from the port's endpoint data.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 32 +++-
drivers/gpu/drm/msm/msm_drv.h | 1 +
2 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 531e4ac..cf72eda 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -241,22 +241,36 @@ int mdp4_enable(struct mdp4_kms *mdp4_kms)
}
#ifdef CONFIG_OF
-static struct drm_panel *detect_panel(struct drm_device *dev, const char *name)
+static struct drm_panel *detect_panel(struct drm_device *dev)
{
- struct device_node *n;
+ struct device_node *endpoint, *panel_node;
+ struct device_node *np = dev-dev-of_node;
struct drm_panel *panel = NULL;
- n = of_parse_phandle(dev-dev-of_node, name, 0);
- if (n) {
- panel = of_drm_find_panel(n);
- if (!panel)
- panel = ERR_PTR(-EPROBE_DEFER);
+ endpoint = of_graph_get_next_endpoint(np, NULL);
+ if (IS_ERR(endpoint)) {
+ dev_err(dev-dev, no valid endpoint\n);
+ return ERR_CAST(endpoint);
}
+ of_node_put(endpoint);
+
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (IS_ERR(panel_node)) {
+ dev_err(dev-dev, no valid panel node\n);
+ return ERR_CAST(panel_node);
+ }
+
+ of_node_put(panel_node);
+
+ panel = of_drm_find_panel(panel_node);
+ if (IS_ERR(panel))
+ panel = ERR_PTR(-EPROBE_DEFER);
+
return panel;
}
#else
-static struct drm_panel *detect_panel(struct drm_device *dev, const char *name)
+static struct drm_panel *detect_panel(struct drm_device *dev)
{
// ??? maybe use a module param to specify which panel is attached?
}
@@ -294,7 +308,7 @@ static int modeset_init(struct mdp4_kms *mdp4_kms)
* Setup the LCDC/LVDS path: RGB2 - DMA_P - LCDC - LVDS:
*/
- panel = detect_panel(dev, qcom,lvds-panel);
+ panel = detect_panel(dev);
if (IS_ERR(panel)) {
ret = PTR_ERR(panel);
dev_err(dev-dev, failed to detect LVDS panel: %d\n, ret);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index e7c5ea1..0cbeb1d 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -30,6 +30,7 @@
#include linux/list.h
#include linux/iommu.h
#include linux/types.h
+#include linux/of_graph.h
#include asm/sizes.h
#ifndef CONFIG_OF
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drm/msm: dsi host: Use device graph parsing to parse connected panel
The dsi host looks for the connected panel node by parsing for a child
named 'panel'. This hierarchy isn't very flexible. The connected
panel is forced to be a child to the dsi host, and hence, a mipi dsi
device. This isn't suitable for dsi devices that don't use mipi dsi
as their control bus.
Follow the of_graph approach of creating ports and endpoints to
represent the connections between the dsi host and the panel connected
to it. In our case, the dsi host will only have one output port, linked
to the panel's input port.
Update DT binding documentation with device graph usage info.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
Documentation/devicetree/bindings/drm/msm/dsi.txt | 15 ++
drivers/gpu/drm/msm/dsi/dsi_host.c| 64 +--
2 files changed, 63 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
index 6ccd860..c88ec3c 100644
--- a/Documentation/devicetree/bindings/drm/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -25,6 +25,9 @@ Required properties:
- vddio-supply: phandle to vdd-io regulator device node
- vdda-supply: phandle to vdda regulator device node
- qcom,dsi-phy: phandle to DSI PHY device node
+- port: DSI controller output port. This contains one endpoint subnode, with
its
+ remote-endpoint set to the phandle of the connected panel's endpoint.
+ See Documentation/devicetree/bindings/graph.txt for device graph info.
Optional properties:
- panel@0: Node of panel connected to this DSI controller.
@@ -101,6 +104,18 @@ Example:
power-supply = ...;
backlight = ...;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = dsi0_out;
+ };
+ };
+ };
+
+ port {
+ dsi0_out: endpoint {
+ remote-endpoint = panel_in;
+ };
};
};
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1751659..ab0b23b 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -20,6 +20,7 @@
#include linux/of_device.h
#include linux/of_gpio.h
#include linux/of_irq.h
+#include linux/of_graph.h
#include linux/regulator/consumer.h
#include linux/spinlock.h
#include video/mipi_display.h
@@ -1379,7 +1380,7 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
msm_host-format = dsi-format;
msm_host-mode_flags = dsi-mode_flags;
- msm_host-panel_node = dsi-dev.of_node;
+ WARN_ON(dsi-dev.of_node != msm_host-panel_node);
/* Some gpios defined in panel DT need to be controlled by host */
ret = dsi_host_init_panel_gpios(msm_host, dsi-dev);
@@ -1429,6 +1430,46 @@ static struct mipi_dsi_host_ops dsi_host_ops = {
.transfer = dsi_host_transfer,
};
+static int msm_dsi_host_parse_dt(struct msm_dsi_host *msm_host)
+{
+ struct device *dev = msm_host-pdev-dev;
+ struct device_node *np = dev-of_node;
+ struct device_node *endpoint, *panel_node;
+ int ret;
+
+ ret = of_property_read_u32(np, qcom,dsi-host-index, msm_host-id);
+ if (ret) {
+ dev_err(dev, %s: host index not specified, ret=%d\n,
+ __func__, ret);
+ return ret;
+ }
+
+ /*
+* get the first endpoint node. in our case, dsi has one output port
+* to which the panel is connected.
+*/
+ endpoint = of_graph_get_next_endpoint(np, NULL);
+ if (IS_ERR(endpoint)) {
+ dev_err(dev, %s: no valid endpoint\n, __func__);
+ return PTR_ERR(endpoint);
+ }
+
+ of_node_put(endpoint);
+
+ /* get panel node from the output port's endpoint data */
+ panel_node = of_graph_get_remote_port_parent(endpoint);
+ if (IS_ERR(panel_node)) {
+ dev_err(dev, %s: no valid device\n, __func__);
+ return PTR_ERR(panel_node);
+ }
+
+ of_node_put(panel_node);
+
+ msm_host-panel_node = panel_node;
+
+ return 0;
+}
+
int msm_dsi_host_init(struct msm_dsi *msm_dsi)
{
struct msm_dsi_host *msm_host = NULL;
@@ -1443,15 +1484,13 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
- ret = of_property_read_u32(pdev-dev.of_node,
- qcom,dsi-host-index, msm_host-id);
+ msm_host-pdev = pdev;
+
+ ret = msm_dsi_host_parse_dt(msm_host);
if (ret) {
- dev_err(pdev-dev,
- %s: host index not specified, ret=%d\n,
- __func__, ret);
+ pr_err(%s: failed to parse dt\n, __func__);
goto fail
[PATCH 1/3] drm/msm: dsi host: add missing of_node_put()
Decrement device node refcount if of_get_child_by_name is successfully
called.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index de04009..1751659 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1582,6 +1582,8 @@ int msm_dsi_host_register(struct mipi_dsi_host *host,
bool check_defer)
node = of_get_child_by_name(msm_host-pdev-dev.of_node,
panel);
if (node) {
+ of_node_put(node);
+
if (!of_drm_find_panel(node))
return -EPROBE_DEFER;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/msm/mdp5: release SMB(shared memory blocks) in various cases
On 06/19/2015 11:33 PM, Wentao Xu wrote:
Release all blocks after the pipe is disabled, even when vsync
didn't happen in some error cases. Allow requesting SMB multiple
times before configuring to hardware, by releasing blocks not
programmed to hardware yet for shrinking case.
Tested-by: Archit Taneja arch...@codeaurora.org
Signed-off-by: Wentao Xu went...@codeaurora.org
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 13 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 2 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 33 +---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 87 ++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h | 1 +
5 files changed, 104 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 97226a1..db49ee8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -78,7 +78,20 @@ static void mdp5_prepare_commit(struct msm_kms *kms, struct
drm_atomic_state *st
static void mdp5_complete_commit(struct msm_kms *kms, struct drm_atomic_state
*state)
{
+ int i;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+ int nplanes = mdp5_kms-dev-mode_config.num_total_plane;
+
+ for (i = 0; i nplanes; i++) {
+ struct drm_plane *plane = state-planes[i];
+ struct drm_plane_state *plane_state = state-plane_states[i];
+
+ if (!plane)
+ continue;
+
+ mdp5_plane_complete_commit(plane, plane_state);
+ }
+
mdp5_disable(mdp5_kms);
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 2c0de17..42f270b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -227,6 +227,8 @@ void mdp5_plane_install_properties(struct drm_plane *plane,
struct drm_mode_object *obj);
uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
void mdp5_plane_complete_flip(struct drm_plane *plane);
+void mdp5_plane_complete_commit(struct drm_plane *plane,
+ struct drm_plane_state *state);
enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 18a3d20..05b2634 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -31,8 +31,6 @@ struct mdp5_plane {
uint32_t nformats;
uint32_t formats[32];
-
- bool enabled;
};
#define to_mdp5_plane(x) container_of(x, struct mdp5_plane, base)
@@ -56,22 +54,6 @@ static bool plane_enabled(struct drm_plane_state *state)
return state-fb state-crtc;
}
-static int mdp5_plane_disable(struct drm_plane *plane)
-{
- struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
- struct mdp5_kms *mdp5_kms = get_kms(plane);
- enum mdp5_pipe pipe = mdp5_plane-pipe;
-
- DBG(%s: disable, mdp5_plane-name);
-
- if (mdp5_kms) {
- /* Release the memory we requested earlier from the SMP: */
- mdp5_smp_release(mdp5_kms-smp, pipe);
- }
-
- return 0;
-}
-
static void mdp5_plane_destroy(struct drm_plane *plane)
{
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
@@ -224,7 +206,6 @@ static void mdp5_plane_atomic_update(struct drm_plane
*plane,
if (!plane_enabled(state)) {
to_mdp5_plane_state(state)-pending = true;
- mdp5_plane_disable(plane);
} else if (to_mdp5_plane_state(state)-mode_changed) {
int ret;
to_mdp5_plane_state(state)-pending = true;
@@ -602,6 +583,20 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
return mdp5_plane-flush_mask;
}
+/* called after vsync in thread context */
+void mdp5_plane_complete_commit(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct mdp5_kms *mdp5_kms = get_kms(plane);
+ struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
+ enum mdp5_pipe pipe = mdp5_plane-pipe;
+
+ if (!plane_enabled(plane-state)) {
+ DBG(%s: free SMP, mdp5_plane-name);
+ mdp5_smp_release(mdp5_kms-smp, pipe);
+ }
+}
+
/* initialize plane */
struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
index 16702ae..64a27d8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
@@ -34,22 +34,44 @@
* and CANNOT be re-allocated (eg: MMB0 and MMB1 both tied to RGB0).
*
* For each block that can
Re: [PATCH 1/3] drm/msm: dsi host: add missing of_node_put()
On 06/22/2015 09:30 PM, Srinivas Kandagatla wrote:
On 22/06/15 15:54, Archit Taneja wrote:
Decrement device node refcount if of_get_child_by_name is successfully
called.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index de04009..1751659 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1582,6 +1582,8 @@ int msm_dsi_host_register(struct mipi_dsi_host
*host, bool check_defer)
node = of_get_child_by_name(msm_host-pdev-dev.of_node,
panel);
if (node) {
+of_node_put(node);
+
Atleast from the current state of code, It looks like the driver is
going to refer to the node of_node_put?, So I think this is not the
right place to have of_node_put.
That's right. I made the same mistake in the later patches too. I'll fix
these.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/msm/mdp5: Always generate active-high sync signals for DSI
On 05/22/2015 07:46 PM, Hai Li wrote:
DSI video mode engine can only take active-high sync signals. This
change prevents MDP5 sending active-low sync signals to DSI in any
case.
Signed-off-by: Hai Li
Tested-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 53bb1f7..2e98ce0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -144,10 +144,14 @@ static void mdp5_encoder_mode_set(struct drm_encoder
*encoder,
mode->type, mode->flags);
ctrl_pol = 0;
- if (mode->flags & DRM_MODE_FLAG_NHSYNC)
- ctrl_pol |= MDP5_INTF_POLARITY_CTL_HSYNC_LOW;
- if (mode->flags & DRM_MODE_FLAG_NVSYNC)
- ctrl_pol |= MDP5_INTF_POLARITY_CTL_VSYNC_LOW;
+
+ /* DSI controller cannot handle active-low sync signals. */
+ if (mdp5_encoder->intf.type != INTF_DSI) {
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+ ctrl_pol |= MDP5_INTF_POLARITY_CTL_HSYNC_LOW;
+ if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+ ctrl_pol |= MDP5_INTF_POLARITY_CTL_VSYNC_LOW;
+ }
/* probably need to get DATA_EN polarity from panel.. */
dtv_hsync_skew = 0; /* get this from panel? */
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/msm/mdp5: Always generate active-high sync signals for DSI
On 05/22/2015 07:46 PM, Hai Li wrote:
DSI video mode engine can only take active-high sync signals. This
change prevents MDP5 sending active-low sync signals to DSI in any
case.
Signed-off-by: Hai Li h...@codeaurora.org
Tested-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 53bb1f7..2e98ce0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -144,10 +144,14 @@ static void mdp5_encoder_mode_set(struct drm_encoder
*encoder,
mode-type, mode-flags);
ctrl_pol = 0;
- if (mode-flags DRM_MODE_FLAG_NHSYNC)
- ctrl_pol |= MDP5_INTF_POLARITY_CTL_HSYNC_LOW;
- if (mode-flags DRM_MODE_FLAG_NVSYNC)
- ctrl_pol |= MDP5_INTF_POLARITY_CTL_VSYNC_LOW;
+
+ /* DSI controller cannot handle active-low sync signals. */
+ if (mdp5_encoder-intf.type != INTF_DSI) {
+ if (mode-flags DRM_MODE_FLAG_NHSYNC)
+ ctrl_pol |= MDP5_INTF_POLARITY_CTL_HSYNC_LOW;
+ if (mode-flags DRM_MODE_FLAG_NVSYNC)
+ ctrl_pol |= MDP5_INTF_POLARITY_CTL_VSYNC_LOW;
+ }
/* probably need to get DATA_EN polarity from panel.. */
dtv_hsync_skew = 0; /* get this from panel? */
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v6 2/2] dmaengine: Add ADM driver
Hi, On 03/17/2015 11:16 AM, Andy Gross wrote: Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA controller found in the MSM8x60 and IPQ/APQ8064 platforms. The ADM supports both memory to memory transactions and memory to/from peripheral device transactions. The controller also provides flow control capabilities for transactions to/from peripheral devices. The initial release of this driver supports slave transfers to/from peripherals and also incorporates CRCI (client rate control interface) flow control. Signed-off-by: Andy Gross --- drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/qcom_adm.c | 900 3 files changed, 911 insertions(+) create mode 100644 drivers/dma/qcom_adm.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index a874b6e..6919013 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -473,4 +473,14 @@ config QCOM_BAM_DMA Enable support for the QCOM BAM DMA controller. This controller provides DMA capabilities for a variety of on-chip devices. +config QCOM_ADM + tristate "Qualcomm ADM support" + depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for the Qualcomm ADM DMA controller. This controller + provides DMA capabilities for both general purpose and on-chip + peripheral devices. + endif diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index f915f61..7f0fbe6 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o +obj-$(CONFIG_QCOM_ADM) += qcom_adm.o diff --git a/drivers/dma/qcom_adm.c b/drivers/dma/qcom_adm.c new file mode 100644 index 000..7f8c119 --- /dev/null +++ b/drivers/dma/qcom_adm.c @@ -0,0 +1,900 @@ +/* + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "dmaengine.h" +#include "virt-dma.h" + +/* ADM registers - calculated from channel number and security domain */ +#define ADM_CHAN_MULTI 0x4 +#define ADM_CI_MULTI 0x4 +#define ADM_CRCI_MULTI 0x4 +#define ADM_EE_MULTI 0x800 +#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan) +#define ADM_EE_OFFS(ee)(ADM_EE_MULTI * ee) +#define ADM_CHAN_EE_OFFS(chan, ee) (ADM_CHAN_OFFS(chan) + ADM_EE_OFFS(ee)) +#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan) +#define ADM_CI_OFFS(ci)(ADM_CHAN_OFF(ci)) +#define ADM_CH_CMD_PTR(chan, ee) (ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_RSLT(chan, ee) (0x40 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_FLUSH_STATE0(chan, ee) (0x80 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_STATUS_SD(chan, ee) (0x200 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_CONF(chan) (0x240 + ADM_CHAN_OFFS(chan)) +#define ADM_CH_RSLT_CONF(chan, ee) (0x300 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_SEC_DOMAIN_IRQ_STATUS(ee) (0x380 + ADM_EE_OFFS(ee)) +#define ADM_CI_CONF(ci)(0x390 + ci * ADM_CI_MULTI) +#define ADM_GP_CTL 0x3d8 +#define ADM_CRCI_CTL(crci, ee) (0x400 + crci * ADM_CRCI_MULTI + \ + ADM_EE_OFFS(ee)) + +/* channel status */ +#define ADM_CH_STATUS_VALIDBIT(1) + +/* channel result */ +#define ADM_CH_RSLT_VALID BIT(31) +#define ADM_CH_RSLT_ERRBIT(3) +#define ADM_CH_RSLT_FLUSH BIT(2) +#define ADM_CH_RSLT_TPDBIT(1) + +/* channel conf */ +#define ADM_CH_CONF_SHADOW_EN BIT(12) +#define ADM_CH_CONF_MPU_DISABLEBIT(11) +#define ADM_CH_CONF_PERM_MPU_CONF BIT(9) +#define ADM_CH_CONF_FORCE_RSLT_EN BIT(7) +#define ADM_CH_CONF_SEC_DOMAIN(ee) (((ee & 0x3) << 4) | ((ee & 0x4) << 11)) + +/* channel result conf */ +#define ADM_CH_RSLT_CONF_FLUSH_EN BIT(1) +#define ADM_CH_RSLT_CONF_IRQ_ENBIT(0) + +/* CRCI CTL */ +#define ADM_CRCI_CTL_MUX_SEL BIT(18) +#define ADM_CRCI_CTL_RST
Re: [Patch v6 2/2] dmaengine: Add ADM driver
Hi, On 03/17/2015 11:16 AM, Andy Gross wrote: Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA controller found in the MSM8x60 and IPQ/APQ8064 platforms. The ADM supports both memory to memory transactions and memory to/from peripheral device transactions. The controller also provides flow control capabilities for transactions to/from peripheral devices. The initial release of this driver supports slave transfers to/from peripherals and also incorporates CRCI (client rate control interface) flow control. Signed-off-by: Andy Gross agr...@codeaurora.org --- drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/qcom_adm.c | 900 3 files changed, 911 insertions(+) create mode 100644 drivers/dma/qcom_adm.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index a874b6e..6919013 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -473,4 +473,14 @@ config QCOM_BAM_DMA Enable support for the QCOM BAM DMA controller. This controller provides DMA capabilities for a variety of on-chip devices. +config QCOM_ADM + tristate Qualcomm ADM support + depends on ARCH_QCOM || (COMPILE_TEST OF ARM) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for the Qualcomm ADM DMA controller. This controller + provides DMA capabilities for both general purpose and on-chip + peripheral devices. + endif diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index f915f61..7f0fbe6 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o +obj-$(CONFIG_QCOM_ADM) += qcom_adm.o diff --git a/drivers/dma/qcom_adm.c b/drivers/dma/qcom_adm.c new file mode 100644 index 000..7f8c119 --- /dev/null +++ b/drivers/dma/qcom_adm.c @@ -0,0 +1,900 @@ +/* + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include linux/kernel.h +#include linux/io.h +#include linux/init.h +#include linux/slab.h +#include linux/module.h +#include linux/interrupt.h +#include linux/dma-mapping.h +#include linux/scatterlist.h +#include linux/device.h +#include linux/platform_device.h +#include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h +#include linux/of_dma.h +#include linux/reset.h +#include linux/clk.h +#include linux/dmaengine.h + +#include dmaengine.h +#include virt-dma.h + +/* ADM registers - calculated from channel number and security domain */ +#define ADM_CHAN_MULTI 0x4 +#define ADM_CI_MULTI 0x4 +#define ADM_CRCI_MULTI 0x4 +#define ADM_EE_MULTI 0x800 +#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan) +#define ADM_EE_OFFS(ee)(ADM_EE_MULTI * ee) +#define ADM_CHAN_EE_OFFS(chan, ee) (ADM_CHAN_OFFS(chan) + ADM_EE_OFFS(ee)) +#define ADM_CHAN_OFFS(chan)(ADM_CHAN_MULTI * chan) +#define ADM_CI_OFFS(ci)(ADM_CHAN_OFF(ci)) +#define ADM_CH_CMD_PTR(chan, ee) (ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_RSLT(chan, ee) (0x40 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_FLUSH_STATE0(chan, ee) (0x80 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_STATUS_SD(chan, ee) (0x200 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_CH_CONF(chan) (0x240 + ADM_CHAN_OFFS(chan)) +#define ADM_CH_RSLT_CONF(chan, ee) (0x300 + ADM_CHAN_EE_OFFS(chan, ee)) +#define ADM_SEC_DOMAIN_IRQ_STATUS(ee) (0x380 + ADM_EE_OFFS(ee)) +#define ADM_CI_CONF(ci)(0x390 + ci * ADM_CI_MULTI) +#define ADM_GP_CTL 0x3d8 +#define ADM_CRCI_CTL(crci, ee) (0x400 + crci * ADM_CRCI_MULTI + \ + ADM_EE_OFFS(ee)) + +/* channel status */ +#define ADM_CH_STATUS_VALIDBIT(1) + +/* channel result */ +#define ADM_CH_RSLT_VALID BIT(31) +#define ADM_CH_RSLT_ERRBIT(3) +#define ADM_CH_RSLT_FLUSH BIT(2) +#define ADM_CH_RSLT_TPDBIT(1) + +/* channel conf */ +#define ADM_CH_CONF_SHADOW_EN BIT(12) +#define ADM_CH_CONF_MPU_DISABLEBIT(11) +#define ADM_CH_CONF_PERM_MPU_CONF BIT(9) +#define ADM_CH_CONF_FORCE_RSLT_EN BIT(7) +#define ADM_CH_CONF_SEC_DOMAIN(ee)
Re: [PATCH] drm/msm: Fix compil issue when DRM_MSM_FBDEV is disabled
Hi,
On 05/06/2015 07:58 PM, Rob Clark wrote:
On Wed, May 6, 2015 at 9:25 AM, Stephane Viau wrote:
When CONFIG_DRM_MSM_FBDEV is not defined,
CONFIG_DRM_KMS_FB_HELPER does not get selected and
drm_fb_helper_*() helper functions are thus not available.
This change fixes these link issues.
Hmm, didn't Archit start on making fbdev config option global and
adding nop-stubs for the case that it was disabled? I lost track of
where that was going..
Daniel and I had thought of a possible solution. I had started working
on it, but it's still work in progress. It required more things to do
than originally thought of.
I don't know if that work will make it in time for 4.2. Maybe we could
pull this for the time being?
Archit
BR,
-R
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 2b1218c..35380ec 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -21,9 +21,11 @@
static void msm_fb_output_poll_changed(struct drm_device *dev)
{
+#ifdef DRM_MSM_FBDEV
struct msm_drm_private *priv = dev->dev_private;
if (priv->fbdev)
drm_fb_helper_hotplug_event(priv->fbdev);
+#endif
}
static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -419,9 +421,11 @@ static void msm_preclose(struct drm_device *dev, struct
drm_file *file)
static void msm_lastclose(struct drm_device *dev)
{
+#ifdef DRM_MSM_FBDEV
struct msm_drm_private *priv = dev->dev_private;
if (priv->fbdev)
drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
+#endif
}
static irqreturn_t msm_irq(int irq, void *arg)
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/msm: Fix compil issue when DRM_MSM_FBDEV is disabled
Hi,
On 05/06/2015 07:58 PM, Rob Clark wrote:
On Wed, May 6, 2015 at 9:25 AM, Stephane Viau sv...@codeaurora.org wrote:
When CONFIG_DRM_MSM_FBDEV is not defined,
CONFIG_DRM_KMS_FB_HELPER does not get selected and
drm_fb_helper_*() helper functions are thus not available.
This change fixes these link issues.
Hmm, didn't Archit start on making fbdev config option global and
adding nop-stubs for the case that it was disabled? I lost track of
where that was going..
Daniel and I had thought of a possible solution. I had started working
on it, but it's still work in progress. It required more things to do
than originally thought of.
I don't know if that work will make it in time for 4.2. Maybe we could
pull this for the time being?
Archit
BR,
-R
Signed-off-by: Stephane Viau sv...@codeaurora.org
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 2b1218c..35380ec 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -21,9 +21,11 @@
static void msm_fb_output_poll_changed(struct drm_device *dev)
{
+#ifdef DRM_MSM_FBDEV
struct msm_drm_private *priv = dev-dev_private;
if (priv-fbdev)
drm_fb_helper_hotplug_event(priv-fbdev);
+#endif
}
static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -419,9 +421,11 @@ static void msm_preclose(struct drm_device *dev, struct
drm_file *file)
static void msm_lastclose(struct drm_device *dev)
{
+#ifdef DRM_MSM_FBDEV
struct msm_drm_private *priv = dev-dev_private;
if (priv-fbdev)
drm_fb_helper_restore_fbdev_mode_unlocked(priv-fbdev);
+#endif
}
static irqreturn_t msm_irq(int irq, void *arg)
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
On 04/09/2015 02:13 PM, Thierry Reding wrote:
On Thu, Feb 12, 2015 at 02:01:34PM +0800, Liu Ying wrote:
[...]
diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c
b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
[...]
+struct dw_mipi_dsi {
+ struct mipi_dsi_host dsi_host;
+ struct drm_connector connector;
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
+ struct device *dev;
+
+ void __iomem *base;
+
+ struct clk *pllref_clk;
+ struct clk *cfg_clk;
+ struct clk *pclk;
+
+ unsigned int lane_mbps; /* per lane */
+ u32 channel;
+ u32 lanes;
+ u32 format;
+ struct drm_display_mode *mode;
+
+ const struct dw_mipi_dsi_plat_data *pdata;
+
+ bool enabled;
+};
While reviewing this I kept thinking whether this is really the right
architectural design. This driver is a MIPI DSI host, a connector and
a bridge, all in one. But it seems to me like it should really be an
encoder/connector and a MIPI DSI host. Why the need for a bridge? The
bridge abstraction targets blocks outside of the SoC, but it is my
understanding that these DesignWare IP blocks are designed into SoCs.
The msm driver uses bridges for blocks within the SoC too. We have too
many sub blocks in the display controller that use up crtcs and encoder
entities. A bridge is the only option one has if an encoder in the
display chain is already taken.
In the above designware configuration, if some one created a board that
used an external chip to further convert DSI to some other output
format, then we would be completely exhausted of all entities.
I posted a patch that allows us to create a chain of bridges for such
cases. It seems to work well as an interim solution. Ideally, it would
be better if we could make bridge a special case of an encoder, and let
one encoder connect to another encoder.
Such a thing would also help us unify i2c slave encoders and bridge
drivers too. A chip designed as an i2c slave encoder would work well
with a drm driver that doesn't have an encoder, but won't work for SoCs
SoCs that already have an encoder and were expecting a bridge entity
instead.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v9 11/20] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
On 04/09/2015 02:13 PM, Thierry Reding wrote:
On Thu, Feb 12, 2015 at 02:01:34PM +0800, Liu Ying wrote:
[...]
diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c
b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
[...]
+struct dw_mipi_dsi {
+ struct mipi_dsi_host dsi_host;
+ struct drm_connector connector;
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
+ struct device *dev;
+
+ void __iomem *base;
+
+ struct clk *pllref_clk;
+ struct clk *cfg_clk;
+ struct clk *pclk;
+
+ unsigned int lane_mbps; /* per lane */
+ u32 channel;
+ u32 lanes;
+ u32 format;
+ struct drm_display_mode *mode;
+
+ const struct dw_mipi_dsi_plat_data *pdata;
+
+ bool enabled;
+};
While reviewing this I kept thinking whether this is really the right
architectural design. This driver is a MIPI DSI host, a connector and
a bridge, all in one. But it seems to me like it should really be an
encoder/connector and a MIPI DSI host. Why the need for a bridge? The
bridge abstraction targets blocks outside of the SoC, but it is my
understanding that these DesignWare IP blocks are designed into SoCs.
The msm driver uses bridges for blocks within the SoC too. We have too
many sub blocks in the display controller that use up crtcs and encoder
entities. A bridge is the only option one has if an encoder in the
display chain is already taken.
In the above designware configuration, if some one created a board that
used an external chip to further convert DSI to some other output
format, then we would be completely exhausted of all entities.
I posted a patch that allows us to create a chain of bridges for such
cases. It seems to work well as an interim solution. Ideally, it would
be better if we could make bridge a special case of an encoder, and let
one encoder connect to another encoder.
Such a thing would also help us unify i2c slave encoders and bridge
drivers too. A chip designed as an i2c slave encoder would work well
with a drm driver that doesn't have an encoder, but won't work for SoCs
SoCs that already have an encoder and were expecting a bridge entity
instead.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] clk: qcom: Add EBI2 clocks for IPQ806x
The NAND controller within EBI2 requires EBI2_CLK and EBI2_ALWAYS_ON_CLK clocks.
Create structs for these clocks so that they can be used by the NAND controller
driver. Add an entry for EBI2_AON_CLK in the gcc-ipq806x DT binding document.
Signed-off-by: Archit Taneja
---
v2:
- removed hwcg_reg/bit entires in ebi2_aon_clk as they only apply to ebi2_clk.
- This was originally a part of the qcom nand controller series. Separating
it out so that it's already there before qcom nand is merged.
drivers/clk/qcom/gcc-ipq806x.c | 32
include/dt-bindings/clock/qcom,gcc-ipq806x.h | 1 +
2 files changed, 33 insertions(+)
diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
index cbdc31d..f7e2d07 100644
--- a/drivers/clk/qcom/gcc-ipq806x.c
+++ b/drivers/clk/qcom/gcc-ipq806x.c
@@ -2170,6 +2170,36 @@ static struct clk_branch usb_fs1_h_clk = {
},
};
+static struct clk_branch ebi2_clk = {
+ .hwcg_reg = 0x3b00,
+ .hwcg_bit = 6,
+ .halt_reg = 0x2fcc,
+ .halt_bit = 1,
+ .clkr = {
+ .enable_reg = 0x3b00,
+ .enable_mask = BIT(4),
+ .hw.init = &(struct clk_init_data){
+ .name = "ebi2_clk",
+ .ops = _branch_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ },
+};
+
+static struct clk_branch ebi2_aon_clk = {
+ .halt_reg = 0x2fcc,
+ .halt_bit = 0,
+ .clkr = {
+ .enable_reg = 0x3b00,
+ .enable_mask = BIT(8),
+ .hw.init = &(struct clk_init_data){
+ .name = "ebi2_always_on_clk",
+ .ops = _branch_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ },
+};
+
static struct clk_regmap *gcc_ipq806x_clks[] = {
[PLL0] = ,
[PLL0_VOTE] = _vote,
@@ -2273,6 +2303,8 @@ static struct clk_regmap *gcc_ipq806x_clks[] = {
[USB_FS1_XCVR_SRC] = _fs1_xcvr_clk_src.clkr,
[USB_FS1_XCVR_CLK] = _fs1_xcvr_clk.clkr,
[USB_FS1_SYSTEM_CLK] = _fs1_sys_clk.clkr,
+ [EBI2_CLK] = _clk.clkr,
+ [EBI2_AON_CLK] = _aon_clk.clkr,
};
static const struct qcom_reset_map gcc_ipq806x_resets[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-ipq806x.h
b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
index 04fb29a..ebd63fd 100644
--- a/include/dt-bindings/clock/qcom,gcc-ipq806x.h
+++ b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
@@ -288,5 +288,6 @@
#define UBI32_CORE2_CLK_SRC278
#define UBI32_CORE1_CLK279
#define UBI32_CORE2_CLK280
+#define EBI2_AON_CLK 281
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] clk: qcom: Add EBI2 clocks for IPQ806x
The NAND controller within EBI2 requires EBI2_CLK and EBI2_ALWAYS_ON_CLK clocks.
Create structs for these clocks so that they can be used by the NAND controller
driver. Add an entry for EBI2_AON_CLK in the gcc-ipq806x DT binding document.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
v2:
- removed hwcg_reg/bit entires in ebi2_aon_clk as they only apply to ebi2_clk.
- This was originally a part of the qcom nand controller series. Separating
it out so that it's already there before qcom nand is merged.
drivers/clk/qcom/gcc-ipq806x.c | 32
include/dt-bindings/clock/qcom,gcc-ipq806x.h | 1 +
2 files changed, 33 insertions(+)
diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
index cbdc31d..f7e2d07 100644
--- a/drivers/clk/qcom/gcc-ipq806x.c
+++ b/drivers/clk/qcom/gcc-ipq806x.c
@@ -2170,6 +2170,36 @@ static struct clk_branch usb_fs1_h_clk = {
},
};
+static struct clk_branch ebi2_clk = {
+ .hwcg_reg = 0x3b00,
+ .hwcg_bit = 6,
+ .halt_reg = 0x2fcc,
+ .halt_bit = 1,
+ .clkr = {
+ .enable_reg = 0x3b00,
+ .enable_mask = BIT(4),
+ .hw.init = (struct clk_init_data){
+ .name = ebi2_clk,
+ .ops = clk_branch_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ },
+};
+
+static struct clk_branch ebi2_aon_clk = {
+ .halt_reg = 0x2fcc,
+ .halt_bit = 0,
+ .clkr = {
+ .enable_reg = 0x3b00,
+ .enable_mask = BIT(8),
+ .hw.init = (struct clk_init_data){
+ .name = ebi2_always_on_clk,
+ .ops = clk_branch_ops,
+ .flags = CLK_IS_ROOT,
+ },
+ },
+};
+
static struct clk_regmap *gcc_ipq806x_clks[] = {
[PLL0] = pll0.clkr,
[PLL0_VOTE] = pll0_vote,
@@ -2273,6 +2303,8 @@ static struct clk_regmap *gcc_ipq806x_clks[] = {
[USB_FS1_XCVR_SRC] = usb_fs1_xcvr_clk_src.clkr,
[USB_FS1_XCVR_CLK] = usb_fs1_xcvr_clk.clkr,
[USB_FS1_SYSTEM_CLK] = usb_fs1_sys_clk.clkr,
+ [EBI2_CLK] = ebi2_clk.clkr,
+ [EBI2_AON_CLK] = ebi2_aon_clk.clkr,
};
static const struct qcom_reset_map gcc_ipq806x_resets[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-ipq806x.h
b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
index 04fb29a..ebd63fd 100644
--- a/include/dt-bindings/clock/qcom,gcc-ipq806x.h
+++ b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
@@ -288,5 +288,6 @@
#define UBI32_CORE2_CLK_SRC278
#define UBI32_CORE1_CLK279
#define UBI32_CORE2_CLK280
+#define EBI2_AON_CLK 281
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool "Enable legacy fbdev support for your modesetting driver"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h
itself, but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap
would actually benefit if we have drm fb helpers for them. They are used
in exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was
considering making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper->fbdev)
fb_deferred_io_init(helper->fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Hi,
On 03/13/2015 02:36 PM, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote:
On 03/11/2015 08:47 PM, Daniel Vetter wrote:
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
On 03/10/2015 03:35 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
Maybe clarify that for linux console support you also need
CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough.
DRM_KMS_FB_HELPER selects that for us, right?
Hm right I've missed that. Reminds me that you need one more patch at the
end to remove all the various select DRM_KMS_FB_HELPER from all drm
drivers. Otherwise this knob here won't work by default if you e.g. select
radeon. In general we can't mix explicit options with menu entries with a
select.
I was trying that out. Removing DRM_KMS_FB_HELPER and having
DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in
their respective xyz_fbdev.c files.
But with the stubbed out functions that should work, right? Why doesn't
it?
There are still calls to functions from fb core like fb_set_suspend and
register_framebuffer which aren't covered by the drm fb helper functions.
Hm, sounds like we need another patch to stub out fb_set_suspend when
fbdev isn't enabled. Is there anything else?
There are a handful of fb core functions which are called by drm drivers:
fb_alloc_cmap/fb_dealloc_cmap
fb_sys_read/fb_sys_write
register_framebuffer/unregister_framebuffer/unlink_framebuffer/
remove_conflicting_framebuffers
fb_set_suspend
fb_deferred_io_init/fb_deferred_io_cleanup
framebuffer_alloc/framebuffer_release
Hm yeah that's somewhat annoying indeed. What about the following:
1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h
2. Then we add stubs for these functions in drm_fb_helper.h, like this
#if defined(CONFIG_FB)
#include linux/fb.h
#else
/* static inline stubs for all the fb stuff used by kms drivers */
#endif
Imo this makes sense since kms drivers really have a bit a special
situation with fbdev. They're not full-blown fbdev drivers and can be
useful fully without fbdev.
I was trying this out. Removing 'linux/fb.h' and replacing stub fb funcs
won't really work because struct declarations(like fb_info) also get
removed.
I considered placing '#if IS_ENABLED(CONFIG_FB)' within linux/fb.h
itself, but that seemed a bit too intrusive.
This is what I'm currently doing:
- Some funcs, like framebufer_alloc/release, alloc_cmap/dealloc_cmap
would actually benefit if we have drm fb helpers for them. They are used
in exactly the same manner by all the drivers.
- For the rest of the functions that are sparsely used, I was
considering making very simple drm_fb_* wrapper functions. Something like:
void drm_fb_helper_deferred_io_init(struct drm_fb_helper *helper)
{
if (helper-fbdev)
fb_deferred_io_init(helper-fbdev);
}
We could have all fb calls called within drm_fb_helper.c, creating
drm_fb_helper_* stub functions would then be an easier task. What do you
think?
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] drm/msm/mdp5: Add START signal to kick off certain pipelines
On 03/24/2015 03:40 AM, "Stéphane Viau" wrote:
Hi Archit,
Hi Stephane,
On 03/14/2015 01:19 AM, Stephane Viau wrote:
Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 7 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 31 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 247
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 72 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 13 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
7 files changed, 276 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index c078f30..72c075a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -31,6 +31,7 @@ const struct mdp5_cfg_hw msm8x74_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
@@ -78,6 +79,7 @@ const struct mdp5_cfg_hw apq8084_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x003f,
msm8x16 would require a flush_hw_mask too, it should be 0x32a59 if I'm
not wrong. Could you please add it for the next revision, or as a part
of the 8x16 hw cfg patch?
Correct; thanks for pointing this out.
IMO, this value should be 0x4003 because the fields are actually
present in the register (even though the interfaces/pipes.etc. are not).
Anyway, these bits won't be accessed because the driver won't even allow
the usage of the corresponding resources.
Okay, that makes sense.
I will update in the v2 of "drm/msm/mdp5: Add hardware configuration for
msm8x16".
Thanks,
Stephane.
Thanks!
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] drm/msm: Initial add DSI connector support
Hi Hai,
On 03/19/2015 02:35 AM, h...@codeaurora.org wrote:
Hi Archit,
Thanks for your comments. Please see my response for some comments below.
Comments without response will be addressed in patch version 2. I will
wait for other comments if any to push patch V2.
+static int dsi_gpio_init(struct msm_dsi_host *msm_host)
+{
+ int ret;
+
+ msm_host->disp_en_gpio = devm_gpiod_get(_host->pdev->dev,
+ "disp-enable");
+ if (IS_ERR(msm_host->disp_en_gpio)) {
+ pr_warn("%s: cannot get disp-enable-gpios %ld\n",
+ __func__, PTR_ERR(msm_host->disp_en_gpio));
+ msm_host->disp_en_gpio = NULL;
+ }
+ if (msm_host->disp_en_gpio) {
+ ret = gpiod_direction_output(msm_host->disp_en_gpio, 0);
+ if (ret) {
+ pr_err("cannot set dir to disp-en-gpios %d\n", ret);
+ return ret;
+ }
+ }
+
+ msm_host->te_gpio = devm_gpiod_get(_host->pdev->dev, "disp-te");
+ if (IS_ERR(msm_host->te_gpio)) {
+ pr_warn("%s: cannot get disp-te-gpios %ld\n",
+ __func__, PTR_ERR(msm_host->te_gpio));
Video mode panels won't have te_gpio, we could probably make this
pr_debug()
+ msm_host->te_gpio = NULL;
+ }
+
+ if (msm_host->te_gpio) {
+ ret = gpiod_direction_input(msm_host->te_gpio);
+ if (ret) {
+ pr_err("%s: cannot set dir to disp-te-gpios, %d\n",
+ __func__, ret);
+ return ret;
+ }
+ }
These gpios currently need to be declared under the dsi DT node. Even if
these are controlled via the dsi host, the gpios should still come under
the panel DT node.
We shout get the panel's of_node here and look for these.
+static void dsi_sw_reset(struct msm_dsi_host *msm_host)
+{
+ dsi_write(msm_host, REG_DSI_CLK_CTRL,
+ DSI_CLK_CTRL_AHBS_HCLK_ON | DSI_CLK_CTRL_AHBM_SCLK_ON |
+ DSI_CLK_CTRL_PCLK_ON | DSI_CLK_CTRL_DSICLK_ON |
+ DSI_CLK_CTRL_BYTECLK_ON | DSI_CLK_CTRL_ESCCLK_ON |
+ DSI_CLK_CTRL_FORCE_ON_DYN_AHBM_HCLK);
The same 7 bits seem to be set elsewhere, maybe make this a macro
DSI_ENABLE_CLKS or something similar?
+int msm_dsi_host_init(struct msm_dsi *msm_dsi)
+{
+ struct msm_dsi_host *msm_host = NULL;
+ struct platform_device *pdev = msm_dsi->pdev;
+ int ret = 0;
+
+ msm_host = devm_kzalloc(>dev, sizeof(*msm_host), GFP_KERNEL);
+ if (!msm_host) {
+ pr_err("%s: FAILED: cannot alloc dsi host\n",
+ __func__);
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ ret = of_property_read_u32(pdev->dev.of_node,
+ "cell-index", _host->id);
retrieving the instance number of a peripheral via a DT property like
'cell-index' has been debated quite a bit in the past. I suppose it's
not the best thing to do.
However, since the DSI instances in MDSS aren't completely identical(one
acts a master and other slave in dual dsi mode), maybe we can get away
with having a property like "qcom,dsi-master;", and that can be further
used to identify whether this node is DSI_0 or DSI_1
2 DSIs are not always master-slave mode. It is possible that a single
panel is connected to any of the hosts, or 2 panels are controlled
independently. If 'cell-index' is not allowed to specify the instance
number, i would prefer to have a simple property like
"qcom,dsi-host-index".
Okay, thanks for that clarification.
+int msm_dsi_host_register(struct mipi_dsi_host *host, bool check_defer)
+{
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+ struct device_node *node;
+ int ret;
+
+ /* Register mipi dsi host */
+ if (!msm_host->registered) {
+ host->dev = _host->pdev->dev;
+ host->ops = _host_ops;
+ ret = mipi_dsi_host_register(host);
+ if (ret)
+ return ret;
+
+ msm_host->registered = true;
+
+ /* If the panel driver has not been probed after host register,
+* we should defer the host's probe.
+* It makes sure panel is connected when fbcon detects
+* connector status and gets the proper display mode to
+* create framebuffer.
+*/
+ if (check_defer) {
+ node = of_parse_phandle(msm_host->pdev->dev.of_node,
+ "qcom,panel", 0);
+ if (node) {
+ if (!of_drm_find_panel(node))
+ return -EPROBE_DEFER;
+ }
+ }
+ }
We might have to defer probe multiple times before
Re: [PATCH v3 3/4] drm/msm/mdp5: Add START signal to kick off certain pipelines
Hi Stephane,
On 03/14/2015 01:19 AM, Stephane Viau wrote:
Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 7 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 31 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 247
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 72 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 13 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
7 files changed, 276 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index c078f30..72c075a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -31,6 +31,7 @@ const struct mdp5_cfg_hw msm8x74_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
@@ -78,6 +79,7 @@ const struct mdp5_cfg_hw apq8084_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x003f,
msm8x16 would require a flush_hw_mask too, it should be 0x32a59 if I'm
not wrong. Could you please add it for the next revision, or as a part
of the 8x16 hw cfg patch?
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] drm/msm/mdp5: Add START signal to kick off certain pipelines
Hi Stephane,
On 03/14/2015 01:19 AM, Stephane Viau wrote:
Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
Signed-off-by: Stephane Viau sv...@codeaurora.org
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 7 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 31 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 247
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 72 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 13 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
7 files changed, 276 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index c078f30..72c075a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -31,6 +31,7 @@ const struct mdp5_cfg_hw msm8x74_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
@@ -78,6 +79,7 @@ const struct mdp5_cfg_hw apq8084_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x003f,
msm8x16 would require a flush_hw_mask too, it should be 0x32a59 if I'm
not wrong. Could you please add it for the next revision, or as a part
of the 8x16 hw cfg patch?
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] drm/msm: Initial add DSI connector support
Hi Hai,
On 03/19/2015 02:35 AM, h...@codeaurora.org wrote:
Hi Archit,
Thanks for your comments. Please see my response for some comments below.
Comments without response will be addressed in patch version 2. I will
wait for other comments if any to push patch V2.
+static int dsi_gpio_init(struct msm_dsi_host *msm_host)
+{
+ int ret;
+
+ msm_host-disp_en_gpio = devm_gpiod_get(msm_host-pdev-dev,
+ disp-enable);
+ if (IS_ERR(msm_host-disp_en_gpio)) {
+ pr_warn(%s: cannot get disp-enable-gpios %ld\n,
+ __func__, PTR_ERR(msm_host-disp_en_gpio));
+ msm_host-disp_en_gpio = NULL;
+ }
+ if (msm_host-disp_en_gpio) {
+ ret = gpiod_direction_output(msm_host-disp_en_gpio, 0);
+ if (ret) {
+ pr_err(cannot set dir to disp-en-gpios %d\n, ret);
+ return ret;
+ }
+ }
+
+ msm_host-te_gpio = devm_gpiod_get(msm_host-pdev-dev, disp-te);
+ if (IS_ERR(msm_host-te_gpio)) {
+ pr_warn(%s: cannot get disp-te-gpios %ld\n,
+ __func__, PTR_ERR(msm_host-te_gpio));
Video mode panels won't have te_gpio, we could probably make this
pr_debug()
+ msm_host-te_gpio = NULL;
+ }
+
+ if (msm_host-te_gpio) {
+ ret = gpiod_direction_input(msm_host-te_gpio);
+ if (ret) {
+ pr_err(%s: cannot set dir to disp-te-gpios, %d\n,
+ __func__, ret);
+ return ret;
+ }
+ }
These gpios currently need to be declared under the dsi DT node. Even if
these are controlled via the dsi host, the gpios should still come under
the panel DT node.
We shout get the panel's of_node here and look for these.
+static void dsi_sw_reset(struct msm_dsi_host *msm_host)
+{
+ dsi_write(msm_host, REG_DSI_CLK_CTRL,
+ DSI_CLK_CTRL_AHBS_HCLK_ON | DSI_CLK_CTRL_AHBM_SCLK_ON |
+ DSI_CLK_CTRL_PCLK_ON | DSI_CLK_CTRL_DSICLK_ON |
+ DSI_CLK_CTRL_BYTECLK_ON | DSI_CLK_CTRL_ESCCLK_ON |
+ DSI_CLK_CTRL_FORCE_ON_DYN_AHBM_HCLK);
The same 7 bits seem to be set elsewhere, maybe make this a macro
DSI_ENABLE_CLKS or something similar?
+int msm_dsi_host_init(struct msm_dsi *msm_dsi)
+{
+ struct msm_dsi_host *msm_host = NULL;
+ struct platform_device *pdev = msm_dsi-pdev;
+ int ret = 0;
+
+ msm_host = devm_kzalloc(pdev-dev, sizeof(*msm_host), GFP_KERNEL);
+ if (!msm_host) {
+ pr_err(%s: FAILED: cannot alloc dsi host\n,
+ __func__);
+ ret = -ENOMEM;
+ goto fail;
+ }
+
+ ret = of_property_read_u32(pdev-dev.of_node,
+ cell-index, msm_host-id);
retrieving the instance number of a peripheral via a DT property like
'cell-index' has been debated quite a bit in the past. I suppose it's
not the best thing to do.
However, since the DSI instances in MDSS aren't completely identical(one
acts a master and other slave in dual dsi mode), maybe we can get away
with having a property like qcom,dsi-master;, and that can be further
used to identify whether this node is DSI_0 or DSI_1
2 DSIs are not always master-slave mode. It is possible that a single
panel is connected to any of the hosts, or 2 panels are controlled
independently. If 'cell-index' is not allowed to specify the instance
number, i would prefer to have a simple property like
qcom,dsi-host-index.
Okay, thanks for that clarification.
+int msm_dsi_host_register(struct mipi_dsi_host *host, bool check_defer)
+{
+ struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+ struct device_node *node;
+ int ret;
+
+ /* Register mipi dsi host */
+ if (!msm_host-registered) {
+ host-dev = msm_host-pdev-dev;
+ host-ops = dsi_host_ops;
+ ret = mipi_dsi_host_register(host);
+ if (ret)
+ return ret;
+
+ msm_host-registered = true;
+
+ /* If the panel driver has not been probed after host register,
+* we should defer the host's probe.
+* It makes sure panel is connected when fbcon detects
+* connector status and gets the proper display mode to
+* create framebuffer.
+*/
+ if (check_defer) {
+ node = of_parse_phandle(msm_host-pdev-dev.of_node,
+ qcom,panel, 0);
+ if (node) {
+ if (!of_drm_find_panel(node))
+ return -EPROBE_DEFER;
+ }
+ }
+ }
We might have to defer probe multiple times before another dependency is
met. The
Re: [PATCH v3 3/4] drm/msm/mdp5: Add START signal to kick off certain pipelines
On 03/24/2015 03:40 AM, Stéphane Viau wrote:
Hi Archit,
Hi Stephane,
On 03/14/2015 01:19 AM, Stephane Viau wrote:
Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
Signed-off-by: Stephane Viau sv...@codeaurora.org
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 7 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 31 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 247
drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h | 72 +++-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 13 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 1 +
7 files changed, 276 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index c078f30..72c075a 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -31,6 +31,7 @@ const struct mdp5_cfg_hw msm8x74_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x0003,
},
.pipe_vig = {
.count = 3,
@@ -78,6 +79,7 @@ const struct mdp5_cfg_hw apq8084_config = {
.ctl = {
.count = 5,
.base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+ .flush_hw_mask = 0x003f,
msm8x16 would require a flush_hw_mask too, it should be 0x32a59 if I'm
not wrong. Could you please add it for the next revision, or as a part
of the 8x16 hw cfg patch?
Correct; thanks for pointing this out.
IMO, this value should be 0x4003 because the fields are actually
present in the register (even though the interfaces/pipes.etc. are not).
Anyway, these bits won't be accessed because the driver won't even allow
the usage of the corresponding resources.
Okay, that makes sense.
I will update in the v2 of drm/msm/mdp5: Add hardware configuration for
msm8x16.
Thanks,
Stephane.
Thanks!
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: qcom: fix RCG M/N counter configuration
On 03/20/2015 10:58 AM, Stephen Boyd wrote: On 03/04, Archit Taneja wrote: Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N. In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1. Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division. Signed-off-by: Archit Taneja --- I'm going to queue this up for 4.1 given that this isn't a new regression. But I'll tag it for stable so that we get it into all the stable trees. Great, that sounds good. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: qcom: fix RCG M/N counter configuration
On 03/20/2015 10:58 AM, Stephen Boyd wrote: On 03/04, Archit Taneja wrote: Currently, a RCG's M/N counter (used for fraction division) is set to either 'bypass' (counter disabled) or 'dual edge' (counter enabled) based on whether the corresponding rcg struct has a mnd field specified and a non-zero N. In the case where M and N are the same value, the M/N counter is still enabled by code even though no division takes place. Leaving the RCG in such a state can result in improper behavior. This was observed with the DSI pixel clock RCG when M and N were both set to 1. Add an additional check (M != N) to enable the M/N counter only when it's needed for fraction division. Signed-off-by: Archit Taneja arch...@codeaurora.org --- I'm going to queue this up for 4.1 given that this isn't a new regression. But I'll tag it for stable so that we get it into all the stable trees. Great, that sounds good. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] drm/msm: Initial add DSI connector support
Hi,
On 03/14/2015 04:54 AM, Hai Li wrote:
This change adds the DSI connector support in msm drm driver.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/Kconfig | 11 +
drivers/gpu/drm/msm/Makefile |4 +
drivers/gpu/drm/msm/dsi/dsi.c | 203
drivers/gpu/drm/msm/dsi/dsi.h | 115 ++
drivers/gpu/drm/msm/dsi/dsi_host.c| 1997 +
drivers/gpu/drm/msm/dsi/dsi_manager.c | 706
drivers/gpu/drm/msm/dsi/dsi_phy.c | 352 ++
drivers/gpu/drm/msm/msm_drv.h | 20 +
8 files changed, 3408 insertions(+)
create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1e6a907..5ba5631 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
Compile in support for logging register reads/writes in a format
that can be parsed by envytools demsm tool. If enabled, register
logging can be switched on via msm.reglog=y module param.
+
+config DRM_MSM_DSI
+ bool "Enable DSI support in MSM DRM driver"
+ depends on DRM_MSM
+ select DRM_PANEL
+ select DRM_MIPI_DSI
+ default y
+ help
+ Choose this option if you have a need for MIPI DSI connector
+ support.
+
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 674a132..5c144cc 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -50,5 +50,9 @@ msm-y := \
msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+ dsi/dsi_host.o \
+ dsi/dsi_manager.o \
+ dsi/dsi_phy.o
obj-$(CONFIG_DRM_MSM) += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
new file mode 100644
index 000..de77260
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "dsi.h"
+
+int msm_dsi_modeset_init(struct msm_drm_sub_dev *base, struct drm_device *dev)
+{
+ struct msm_dsi *msm_dsi = container_of(base, struct msm_dsi, base);
+ struct msm_drm_private *priv = dev->dev_private;
+ int ret, i;
+
+ if (WARN_ON((base->num_encoders != MSM_DSI_ENCODER_NUM) ||
+ !base->encoders[MSM_DSI_VIDEO_ENCODER_ID] ||
+ !base->encoders[MSM_DSI_CMD_ENCODER_ID]))
+ return -EINVAL;
+
+ msm_dsi->dev = dev;
+
+ ret = msm_dsi_host_modeset_init(msm_dsi->host, dev);
+ if (ret) {
+ dev_err(dev->dev, "failed to modeset init host: %d\n", ret);
+ goto fail;
+ }
+
+ msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
+ if (IS_ERR(msm_dsi->bridge)) {
+ ret = PTR_ERR(msm_dsi->bridge);
+ dev_err(dev->dev, "failed to create dsi bridge: %d\n", ret);
+ msm_dsi->bridge = NULL;
+ goto fail;
+ }
+
+ msm_dsi->connector = msm_dsi_manager_connector_init(msm_dsi->id);
+ if (IS_ERR(msm_dsi->connector)) {
+ ret = PTR_ERR(msm_dsi->connector);
+ dev_err(dev->dev, "failed to create dsi connector: %d\n", ret);
+ msm_dsi->connector = NULL;
+ goto fail;
+ }
+
+ for (i = 0; i < base->num_encoders; i++)
+ base->encoders[i]->bridge = msm_dsi->bridge;
+
+ priv->bridges[priv->num_bridges++] = msm_dsi->bridge;
+ priv->connectors[priv->num_connectors++] = msm_dsi->connector;
+
+ return 0;
+fail:
+ if (msm_dsi) {
+ /* bridge/connector are normally destroyed by drm: */
+ if (msm_dsi->bridge) {
+ msm_dsi_manager_bridge_destroy(msm_dsi->bridge);
+ msm_dsi->bridge = NULL;
+ }
+ if (msm_dsi->connector) {
+ msm_dsi->connector->funcs->destroy(msm_dsi->connector);
+ msm_dsi->connector = NULL;
+ }
+ }
+
+ return ret;
+}
+
+static void dsi_destroy(struct
Re: [PATCH 3/4] drm/msm: Initial add DSI connector support
Hi,
On 03/14/2015 04:54 AM, Hai Li wrote:
This change adds the DSI connector support in msm drm driver.
Signed-off-by: Hai Li h...@codeaurora.org
---
drivers/gpu/drm/msm/Kconfig | 11 +
drivers/gpu/drm/msm/Makefile |4 +
drivers/gpu/drm/msm/dsi/dsi.c | 203
drivers/gpu/drm/msm/dsi/dsi.h | 115 ++
drivers/gpu/drm/msm/dsi/dsi_host.c| 1997 +
drivers/gpu/drm/msm/dsi/dsi_manager.c | 706
drivers/gpu/drm/msm/dsi/dsi_phy.c | 352 ++
drivers/gpu/drm/msm/msm_drv.h | 20 +
8 files changed, 3408 insertions(+)
create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1e6a907..5ba5631 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
Compile in support for logging register reads/writes in a format
that can be parsed by envytools demsm tool. If enabled, register
logging can be switched on via msm.reglog=y module param.
+
+config DRM_MSM_DSI
+ bool Enable DSI support in MSM DRM driver
+ depends on DRM_MSM
+ select DRM_PANEL
+ select DRM_MIPI_DSI
+ default y
+ help
+ Choose this option if you have a need for MIPI DSI connector
+ support.
+
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 674a132..5c144cc 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -50,5 +50,9 @@ msm-y := \
msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+ dsi/dsi_host.o \
+ dsi/dsi_manager.o \
+ dsi/dsi_phy.o
obj-$(CONFIG_DRM_MSM) += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
new file mode 100644
index 000..de77260
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include dsi.h
+
+int msm_dsi_modeset_init(struct msm_drm_sub_dev *base, struct drm_device *dev)
+{
+ struct msm_dsi *msm_dsi = container_of(base, struct msm_dsi, base);
+ struct msm_drm_private *priv = dev-dev_private;
+ int ret, i;
+
+ if (WARN_ON((base-num_encoders != MSM_DSI_ENCODER_NUM) ||
+ !base-encoders[MSM_DSI_VIDEO_ENCODER_ID] ||
+ !base-encoders[MSM_DSI_CMD_ENCODER_ID]))
+ return -EINVAL;
+
+ msm_dsi-dev = dev;
+
+ ret = msm_dsi_host_modeset_init(msm_dsi-host, dev);
+ if (ret) {
+ dev_err(dev-dev, failed to modeset init host: %d\n, ret);
+ goto fail;
+ }
+
+ msm_dsi-bridge = msm_dsi_manager_bridge_init(msm_dsi-id);
+ if (IS_ERR(msm_dsi-bridge)) {
+ ret = PTR_ERR(msm_dsi-bridge);
+ dev_err(dev-dev, failed to create dsi bridge: %d\n, ret);
+ msm_dsi-bridge = NULL;
+ goto fail;
+ }
+
+ msm_dsi-connector = msm_dsi_manager_connector_init(msm_dsi-id);
+ if (IS_ERR(msm_dsi-connector)) {
+ ret = PTR_ERR(msm_dsi-connector);
+ dev_err(dev-dev, failed to create dsi connector: %d\n, ret);
+ msm_dsi-connector = NULL;
+ goto fail;
+ }
+
+ for (i = 0; i base-num_encoders; i++)
+ base-encoders[i]-bridge = msm_dsi-bridge;
+
+ priv-bridges[priv-num_bridges++] = msm_dsi-bridge;
+ priv-connectors[priv-num_connectors++] = msm_dsi-connector;
+
+ return 0;
+fail:
+ if (msm_dsi) {
+ /* bridge/connector are normally destroyed by drm: */
+ if (msm_dsi-bridge) {
+ msm_dsi_manager_bridge_destroy(msm_dsi-bridge);
+ msm_dsi-bridge = NULL;
+ }
+ if (msm_dsi-connector) {
+ msm_dsi-connector-funcs-destroy(msm_dsi-connector);
+ msm_dsi-connector = NULL;
+ }
+ }
+
+ return ret;
+}
+
+static void dsi_destroy(struct msm_dsi *msm_dsi)
+{
+ if
Re: [PATCH 5/5] drm/msm/mdp5: Add hardware configuration for msm8x16
On 03/14/2015 01:15 AM, "Stéphane Viau" wrote:
Hi,
Hi,
On 03/09/2015 06:41 PM, Stephane Viau wrote:
This change adds the hw configuration for msm8x16 chipsets in
mdp5_cfg module.
Note that only one external display interface is present in this
configuration (DSI) but has not been enabled yet. It will be enabled
once drm/msm driver supports DSI connectors.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 51
-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 96ea6dd..9ff7ac1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2015 The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or
modify
* it under the terms of the GNU General Public License version 2 and
@@ -150,10 +150,59 @@ const struct mdp5_cfg_hw apq8084_config = {
.max_clk = 32000,
};
+const struct mdp5_cfg_hw msm8x16_config = {
+ .name = "msm8x16",
+ .mdp = {
+ .count = 1,
+ .base = { 0x01000 },
+ },
+ .smp = {
+ .mmb_count = 8,
+ .mmb_size = 8192,
+ .clients = {
+ [SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
+ },
+ },
+ .ctl = {
+ .count = 5,
+ .base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x05000 },
+ },
+ .pipe_rgb = {
+ .count = 2,
+ .base = { 0x15000, 0x17000 },
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x25000 },
+ },
+ .lm = {
+ .count = 2, /* LM0 and LM3 */
+ .base = { 0x45000, 0x48000 },
+ .nb_stages = 5,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x55000 },
+
+ },
+ .intf = {
+ .count = 1, /* INTF_1 */
+ .base = { 0x6B800 },
We would need to put the other non-existent INTF_0, INTF_2 and INTF_3
base addresses here too, so that the writes to
REG_MDP5_INTF_TIMING_ENGINE_EN in the patch "Make the intf connection in
config module" access the correct registers.
You are referring here to the discussion we had in "drm/msm/mdp5: Make the
intf connection in config module"[1]...
Let me clarify:
We see these faults when interfaces are *present* but not *supported* by
the driver, where:
- *present* means that the interfaces are physically implemented in HW
and therefore need to be reflected by "intf.base" addresses
- *supported* means that the msm KMS driver is actually able to drive an
interface
If you look at mdp5_cfg.c in "drm/msm/mdp5: Make the intf connection in
config module"[1], 4 interfaces (intf.base) are present (for apq8084), but
only 2 are supported (intfs[])...
What I meant is that even though our driver cannot support all interfaces
present in a chip, we still need to disable them in mdp5_kms_init().
(BTW, this is probably due to my bootloader enabling the DSI whereas the
msm KMS driver does not support it as of yet - and thus leads to
artifacts/underflow on my eDP panel.)
Okay, I get it now. I think I wasn't sure about whether INTF_DISABLED
represents *present* or *supported*. Thanks for the clarification.
So to answer your comment, it doesn't make too much sense to define base
addresses for interfaces that are not present in a chip. Instead I'd
prefer to check if intf.base is not NULL before writing in
REG_MDP5_INTF_TIMING_ENGINE_EN registers.. and avoid some INVALID_INDEX
BUGs ;-).
That sounds good. Thanks.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] drm/msm/mdp5: Add hardware configuration for msm8x16
On 03/14/2015 01:15 AM, Stéphane Viau wrote:
Hi,
Hi,
On 03/09/2015 06:41 PM, Stephane Viau wrote:
This change adds the hw configuration for msm8x16 chipsets in
mdp5_cfg module.
Note that only one external display interface is present in this
configuration (DSI) but has not been enabled yet. It will be enabled
once drm/msm driver supports DSI connectors.
Signed-off-by: Stephane Viau sv...@codeaurora.org
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 51
-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 96ea6dd..9ff7ac1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2015 The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or
modify
* it under the terms of the GNU General Public License version 2 and
@@ -150,10 +150,59 @@ const struct mdp5_cfg_hw apq8084_config = {
.max_clk = 32000,
};
+const struct mdp5_cfg_hw msm8x16_config = {
+ .name = msm8x16,
+ .mdp = {
+ .count = 1,
+ .base = { 0x01000 },
+ },
+ .smp = {
+ .mmb_count = 8,
+ .mmb_size = 8192,
+ .clients = {
+ [SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
+ },
+ },
+ .ctl = {
+ .count = 5,
+ .base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x05000 },
+ },
+ .pipe_rgb = {
+ .count = 2,
+ .base = { 0x15000, 0x17000 },
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x25000 },
+ },
+ .lm = {
+ .count = 2, /* LM0 and LM3 */
+ .base = { 0x45000, 0x48000 },
+ .nb_stages = 5,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x55000 },
+
+ },
+ .intf = {
+ .count = 1, /* INTF_1 */
+ .base = { 0x6B800 },
We would need to put the other non-existent INTF_0, INTF_2 and INTF_3
base addresses here too, so that the writes to
REG_MDP5_INTF_TIMING_ENGINE_EN in the patch Make the intf connection in
config module access the correct registers.
You are referring here to the discussion we had in drm/msm/mdp5: Make the
intf connection in config module[1]...
Let me clarify:
We see these faults when interfaces are *present* but not *supported* by
the driver, where:
- *present* means that the interfaces are physically implemented in HW
and therefore need to be reflected by intf.base addresses
- *supported* means that the msm KMS driver is actually able to drive an
interface
If you look at mdp5_cfg.c in drm/msm/mdp5: Make the intf connection in
config module[1], 4 interfaces (intf.base) are present (for apq8084), but
only 2 are supported (intfs[])...
What I meant is that even though our driver cannot support all interfaces
present in a chip, we still need to disable them in mdp5_kms_init().
(BTW, this is probably due to my bootloader enabling the DSI whereas the
msm KMS driver does not support it as of yet - and thus leads to
artifacts/underflow on my eDP panel.)
Okay, I get it now. I think I wasn't sure about whether INTF_DISABLED
represents *present* or *supported*. Thanks for the clarification.
So to answer your comment, it doesn't make too much sense to define base
addresses for interfaces that are not present in a chip. Instead I'd
prefer to check if intf.base is not NULL before writing in
REG_MDP5_INTF_TIMING_ENGINE_EN registers.. and avoid some INVALID_INDEX
BUGs ;-).
That sounds good. Thanks.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. What do you think? This looks good! I'll give it a try. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Yeah we definitely can't mix select with a user-visible option. I think we just need to fix up the remaining functions and create stubs for them if needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we should still select for fbcon since otherwise tons of bug reports about "where is my fbcon with kms?". I'll give this a try. Although, it would be a better idea to make the drivers not call these at all when fbdev emulation isn't asked for. With the stubs, if someone does try to use the driver with DRM_FBDEV_EMULATION not set, the worst that'll happen would be that the driver fails to probe. Which isn't so bad. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Yeah we definitely can't mix select with a user-visible option. I think we just need to fix up the remaining functions and create stubs for them if needed and then drop all the selects. Well in DRM_FBDEV_EMULATION we should still select for fbcon since otherwise tons of bug reports about where is my fbcon with kms?. I'll give this a try. Although, it would be a better idea to make the drivers not call these at all when fbdev emulation isn't asked for. With the stubs, if someone does try to use the driver with DRM_FBDEV_EMULATION not set, the worst that'll happen would be that the driver fails to probe. Which isn't so bad. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/13/2015 02:36 PM, Daniel Vetter wrote: On Fri, Mar 13, 2015 at 11:55:07AM +0530, Archit Taneja wrote: On 03/11/2015 08:47 PM, Daniel Vetter wrote: On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote: On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Hm, sounds like we need another patch to stub out fb_set_suspend when fbdev isn't enabled. Is there anything else? There are a handful of fb core functions which are called by drm drivers: fb_alloc_cmap/fb_dealloc_cmap fb_sys_read/fb_sys_write register_framebuffer/unregister_framebuffer/unlink_framebuffer/ remove_conflicting_framebuffers fb_set_suspend fb_deferred_io_init/fb_deferred_io_cleanup framebuffer_alloc/framebuffer_release Hm yeah that's somewhat annoying indeed. What about the following: 1. We move all the #include linux/fb.h from drivers into drm_fb_helper.h 2. Then we add stubs for these functions in drm_fb_helper.h, like this #if defined(CONFIG_FB) #include linux/fb.h #else /* static inline stubs for all the fb stuff used by kms drivers */ #endif Imo this makes sense since kms drivers really have a bit a special situation with fbdev. They're not full-blown fbdev drivers and can be useful fully without fbdev. What do you think? This looks good! I'll give it a try. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] drm/msm/mdp5: Add hardware configuration for msm8x16
Hi,
On 03/09/2015 06:41 PM, Stephane Viau wrote:
This change adds the hw configuration for msm8x16 chipsets in
mdp5_cfg module.
Note that only one external display interface is present in this
configuration (DSI) but has not been enabled yet. It will be enabled
once drm/msm driver supports DSI connectors.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 96ea6dd..9ff7ac1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2015 The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -150,10 +150,59 @@ const struct mdp5_cfg_hw apq8084_config = {
.max_clk = 32000,
};
+const struct mdp5_cfg_hw msm8x16_config = {
+ .name = "msm8x16",
+ .mdp = {
+ .count = 1,
+ .base = { 0x01000 },
+ },
+ .smp = {
+ .mmb_count = 8,
+ .mmb_size = 8192,
+ .clients = {
+ [SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
+ },
+ },
+ .ctl = {
+ .count = 5,
+ .base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x05000 },
+ },
+ .pipe_rgb = {
+ .count = 2,
+ .base = { 0x15000, 0x17000 },
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x25000 },
+ },
+ .lm = {
+ .count = 2, /* LM0 and LM3 */
+ .base = { 0x45000, 0x48000 },
+ .nb_stages = 5,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x55000 },
+
+ },
+ .intf = {
+ .count = 1, /* INTF_1 */
+ .base = { 0x6B800 },
We would need to put the other non-existent INTF_0, INTF_2 and INTF_3
base addresses here too, so that the writes to
REG_MDP5_INTF_TIMING_ENGINE_EN in the patch "Make the intf connection in
config module" access the correct registers.
Archit
+ },
+ /* TODO enable .intfs[] with [1] = INTF_DSI, once DSI is implemented */
+ .max_clk = 32000,
+};
+
static const struct mdp5_cfg_handler cfg_handlers[] = {
{ .revision = 0, .config = { .hw = _config } },
{ .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
+ { .revision = 6, .config = { .hw = _config } },
};
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] drm/msm/mdp5: Add hardware configuration for msm8x16
Hi,
On 03/09/2015 06:41 PM, Stephane Viau wrote:
This change adds the hw configuration for msm8x16 chipsets in
mdp5_cfg module.
Note that only one external display interface is present in this
configuration (DSI) but has not been enabled yet. It will be enabled
once drm/msm driver supports DSI connectors.
Signed-off-by: Stephane Viau sv...@codeaurora.org
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 96ea6dd..9ff7ac1 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2015 The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -150,10 +150,59 @@ const struct mdp5_cfg_hw apq8084_config = {
.max_clk = 32000,
};
+const struct mdp5_cfg_hw msm8x16_config = {
+ .name = msm8x16,
+ .mdp = {
+ .count = 1,
+ .base = { 0x01000 },
+ },
+ .smp = {
+ .mmb_count = 8,
+ .mmb_size = 8192,
+ .clients = {
+ [SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
+ [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
+ },
+ },
+ .ctl = {
+ .count = 5,
+ .base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x05000 },
+ },
+ .pipe_rgb = {
+ .count = 2,
+ .base = { 0x15000, 0x17000 },
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x25000 },
+ },
+ .lm = {
+ .count = 2, /* LM0 and LM3 */
+ .base = { 0x45000, 0x48000 },
+ .nb_stages = 5,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x55000 },
+
+ },
+ .intf = {
+ .count = 1, /* INTF_1 */
+ .base = { 0x6B800 },
We would need to put the other non-existent INTF_0, INTF_2 and INTF_3
base addresses here too, so that the writes to
REG_MDP5_INTF_TIMING_ENGINE_EN in the patch Make the intf connection in
config module access the correct registers.
Archit
+ },
+ /* TODO enable .intfs[] with [1] = INTF_DSI, once DSI is implemented */
+ .max_clk = 32000,
+};
+
static const struct mdp5_cfg_handler cfg_handlers[] = {
{ .revision = 0, .config = { .hw = msm8x74_config } },
{ .revision = 2, .config = { .hw = msm8x74_config } },
{ .revision = 3, .config = { .hw = apq8084_config } },
+ { .revision = 6, .config = { .hw = msm8x16_config } },
};
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 05:47 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. But with the stubbed out functions that should work, right? Why doesn't it? There are still calls to functions from fb core like fb_set_suspend and register_framebuffer which aren't covered by the drm fb helper functions. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. The problem with the patch as-is the massive amounts of selects the FB helper still has. We need to get rid of them so that when you disable fbdev emulation you can indeed disable fbcon and the entire fbdev subsystem. I've thought that remove the hidden symbol DRM_KMS_FB_HELPER and moving all the selects to DRM_FBDEV_EMULATION should work out? If that doesn't work we need to look again how to better stub things out I think. That's true. Also, as Jani pointed out, maybe it isn't the best idea to make every kms driver select DRM_FBDEV_EMULATION? Maybe the drivers that are currently built with fbdev emulation by default can add a 'depends on DRM_FBDEV_EMULATION'? Since the config defaults to y, the drivers should run as is. Later, we could take up each driver and build the fb stuff only when DRM_FBDEV_EMULATION is set, like how we do for i915 and msm? Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 09:03 PM, Jani Nikula wrote: On Tue, 10 Mar 2015, Archit Taneja wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Slightly tangential: As a rule of thumb, you should not "select" anything that is visible in menuconfig or has dependencies [1]. This will break the build eventually, and attempts to fix it are troublesome [2]. Thanks, I'll keep this in mind! Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 5/6] drm/imx: Remove local fbdev emulation Kconfig option
On 03/10/2015 04:24 PM, Philipp Zabel wrote: Hi Archit, thanks for the cleanup! Am Dienstag, den 10.03.2015, 15:11 +0530 schrieb Archit Taneja: DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation for the imx kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option where applicable. Using this config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs in certain places. We replace the #ifdef in imx_drm_driver_load with CONFIG_DRM_FBDEV_EMULATION. It's probably okay to get remove the #ifdef itself, but just left it here for now to be safe. It can be removed after some testing. Signed-off-by: Archit Taneja Tested-by: Philipp Zabel (Both with and without the #ifdef CONFIG_DRM_FBDEV_EMULATION removed.) Thanks for testing it out. Although this is for another patch, I think the legacyfb_depth module_param should be removed altogether if CONFIG_DRM_FBDEV_EMULATION is disabled, so maybe that #ifdef should stay. I'll create a patch for that for future revs of this patch set. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
On 03/10/2015 03:31 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:30PM +0530, Archit Taneja wrote:
DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
the i915 kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
fbdev_suspend_work has been removed. This helps us use stub drm helper functions
at not much cost.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i915/Kconfig | 15 ---
drivers/gpu/drm/i915/Makefile| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c | 7 ---
8 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9..bd9ccfc 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,21 +45,6 @@ config DRM_I915_KMS
If in doubt, say "Y".
-config DRM_I915_FBDEV
- bool "Enable legacy fbdev support for the modesetting intel driver"
- depends on DRM_I915
- select DRM_KMS_FB_HELPER
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev
- support. Note that this support also provide the linux console
- support on top of the intel modesetting driver.
-
- If in doubt, say "Y".
-
config DRM_I915_PRELIMINARY_HW_SUPPORT
bool "Enable preliminary support for prerelease Intel hardware by
default"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f019225..3b3325d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,8 +56,8 @@ i915-y += intel_audio.o \
intel_psr.o \
intel_sideband.o \
intel_sprite.o
-i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
+i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
+i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
# modesetting output/encoder code
i915-y += dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e8b18e5..0c8bcd7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
struct intel_fbdev *ifbdev = NULL;
struct intel_framebuffer *fb;
-#ifdef CONFIG_DRM_I915_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_i915_private *dev_priv = dev->dev_private;
ifbdev = dev_priv->fbdev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..e511fa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1819,11 +1819,9 @@ struct drm_i915_private {
struct drm_i915_gem_object *vlv_pctx;
-#ifdef CONFIG_DRM_I915_FBDEV
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
struct work_struct fbdev_suspend_work;
-#endif
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e730789..9cf13e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
-#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
@@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
return NULL;
return fb;
-#else
- return NULL;
-#endif
Won't this now blow up if there's no fbdev? Tbh I prefer a patch to just
replace the CONFIG_ #define and then maybe a 2nd one on top to clean
things up if you feel like. Same for the other changes in this patch.
There are checks for dev_priv->fbdev and dev_priv->fbdev->fb being non
NULL at the start of the function which would prevent that. But you're
right, the first patch for each device can replace the config, the later
ones can take advantage of the stub functions.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:16 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. + config DRM_LOAD_EDID_FIRMWARE bool "Allow to specify an EDID data set instead of probing for it" depends on DRM_KMS_HELPER diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..c1d44b2 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o + +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y) drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o +endif This should work as drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o since both -y and -m are merged together. Ah right. I'll fix that. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool "Enable legacy fbdev support for your modesetting driver" + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Archit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/6] drm/msm: Remove local fbdev emulation Kconfig option
DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the msm kms driver. Replace this with the top level DRM_FBDEV_EMULATION config option where applicable. This also prevents build breaks caused by undefined drm_fb_helper_* functions when legacy fbdev support was disabled. Signed-off-by: Archit Taneja --- drivers/gpu/drm/msm/Kconfig | 14 -- drivers/gpu/drm/msm/Makefile | 2 +- drivers/gpu/drm/msm/msm_drv.c | 4 ++-- 3 files changed, 3 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index bacbbb7..d6f3a4f 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -13,20 +13,6 @@ config DRM_MSM help DRM/KMS driver for MSM/snapdragon. -config DRM_MSM_FBDEV - bool "Enable legacy fbdev support for MSM modesetting driver" - depends on DRM_MSM - select DRM_KMS_FB_HELPER - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - default y - help - Choose this option if you have a need for the legacy fbdev - support. Note that this support also provide the linux console - support on top of the MSM modesetting driver. - config DRM_MSM_REGISTER_LOGGING bool "MSM DRM register logging" depends on DRM_MSM diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index 674a132..40726ad 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -48,7 +48,7 @@ msm-y := \ msm_rd.o \ msm_ringbuffer.o -msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o +msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o obj-$(CONFIG_DRM_MSM) += msm.o diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index a426911..d3e816a 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -54,7 +54,7 @@ module_param(reglog, bool, 0600); #define reglog 0 #endif -#ifdef CONFIG_DRM_MSM_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION static bool fbdev = true; MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer"); module_param(fbdev, bool, 0600); @@ -305,7 +305,7 @@ static int msm_load(struct drm_device *dev, unsigned long flags) drm_mode_config_reset(dev); -#ifdef CONFIG_DRM_MSM_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION if (fbdev) priv->fbdev = msm_fbdev_init(dev); #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 6/6] drm/sti: Remove local fbdev emulation Kconfig option
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation for the sti kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option instead where applicable. We replace the #ifdef in sti_drm_load with CONFIG_DRM_FBDEV_EMULATION. It's probably okay to get remove the #ifdef itself, but just left it here for now to be safe. It can be removed after some testing. Signed-off-by: Archit Taneja --- drivers/gpu/drm/sti/Kconfig | 6 -- drivers/gpu/drm/sti/sti_drm_drv.c | 2 +- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index fbccc10..e3aa5af 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -9,9 +9,3 @@ config DRM_STI select FW_LOADER_USER_HELPER_FALLBACK help Choose this option to enable DRM on STM stiH41x chipset - -config DRM_STI_FBDEV - bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie" - depends on DRM_STI - help - Choose this option to enable FBDEV on top of DRM for STM stiH41x chipset diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c b/drivers/gpu/drm/sti/sti_drm_drv.c index 5239fa1..90f121d 100644 --- a/drivers/gpu/drm/sti/sti_drm_drv.c +++ b/drivers/gpu/drm/sti/sti_drm_drv.c @@ -76,7 +76,7 @@ static int sti_drm_load(struct drm_device *dev, unsigned long flags) drm_helper_disable_unused_functions(dev); -#ifdef CONFIG_DRM_STI_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION drm_fbdev_cma_init(dev, 32, dev->mode_config.num_crtc, dev->mode_config.num_connector); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 4/6] drm/tegra: Remove local fbdev emulation Kconfig option
DRM_TEGRA_FBDEV config is currently used to enable/disable fbdev emulation for
the tegra kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in tegra_drm struct that adds/removes the terga_fbdev member has been
removed completely. This helps in calling stub drm fb helper functions at not
much
cost.
We could clean up fb.c a bit further to reduce the number of #ifdefs, but that's
left for later.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/tegra/Kconfig | 12
drivers/gpu/drm/tegra/drm.c | 15 ++-
drivers/gpu/drm/tegra/drm.h | 8
drivers/gpu/drm/tegra/fb.c| 25 ++---
4 files changed, 16 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d62..63ebb15 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -16,18 +16,6 @@ config DRM_TEGRA
if DRM_TEGRA
-config DRM_TEGRA_FBDEV
- bool "Enable legacy fbdev support"
- select DRM_KMS_FB_HELPER
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev support.
- Note that this support also provides the Linux console on top of
- the Tegra modesetting driver.
-
config DRM_TEGRA_DEBUG
bool "NVIDIA Tegra DRM debug support"
help
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 7dd328d..97ebde9 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -104,11 +104,17 @@ static int tegra_atomic_commit(struct drm_device *drm,
return 0;
}
+static inline void tegra_fb_output_poll_changed(struct drm_device *drm)
+{
+ struct tegra_drm *tegra = drm->dev_private;
+
+ if (tegra->fbdev)
+ drm_fb_helper_hotplug_event(>fbdev->base);
+}
+
static const struct drm_mode_config_funcs tegra_drm_mode_funcs = {
.fb_create = tegra_fb_create,
-#ifdef CONFIG_DRM_TEGRA_FBDEV
.output_poll_changed = tegra_fb_output_poll_changed,
-#endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = tegra_atomic_commit,
};
@@ -248,11 +254,10 @@ static void tegra_drm_context_free(struct
tegra_drm_context *context)
static void tegra_drm_lastclose(struct drm_device *drm)
{
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_drm *tegra = drm->dev_private;
- tegra_fbdev_restore_mode(tegra->fbdev);
-#endif
+ if (tegra->fbdev)
+ drm_fb_helper_restore_fbdev_mode_unlocked(>fbdev->base);
}
static struct host1x_bo *
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 8cb2dfe..3a92413 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -29,12 +29,10 @@ struct tegra_fb {
unsigned int num_planes;
};
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_fbdev {
struct drm_fb_helper base;
struct tegra_fb *fb;
};
-#endif
struct tegra_drm {
struct drm_device *drm;
@@ -45,9 +43,7 @@ struct tegra_drm {
struct mutex clients_lock;
struct list_head clients;
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_fbdev *fbdev;
-#endif
unsigned int pitch_align;
@@ -263,10 +259,6 @@ int tegra_drm_fb_prepare(struct drm_device *drm);
void tegra_drm_fb_free(struct drm_device *drm);
int tegra_drm_fb_init(struct drm_device *drm);
void tegra_drm_fb_exit(struct drm_device *drm);
-#ifdef CONFIG_DRM_TEGRA_FBDEV
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
-void tegra_fb_output_poll_changed(struct drm_device *drm);
-#endif
extern struct platform_driver tegra_dc_driver;
extern struct platform_driver tegra_dsi_driver;
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 397fb34..2eacea2 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -18,7 +18,7 @@ static inline struct tegra_fb *to_tegra_fb(struct
drm_framebuffer *fb)
return container_of(fb, struct tegra_fb, base);
}
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
static inline struct tegra_fbdev *to_tegra_fbdev(struct drm_fb_helper *helper)
{
return container_of(helper, struct tegra_fbdev, base);
@@ -181,7 +181,7 @@ unreference:
return ERR_PTR(err);
}
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
static struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
.fb_fillrect = sys_fillrect,
@@ -371,24 +371,11 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
tegra_fbdev_free(fbdev);
}
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev)
-{
- if (fbdev)
- drm_fb_helper_restore_fbdev_mode_unlocked(>bas
[RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
the i915 kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
fbdev_suspend_work has been removed. This helps us use stub drm helper functions
at not much cost.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i915/Kconfig | 15 ---
drivers/gpu/drm/i915/Makefile| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c | 7 ---
8 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9..bd9ccfc 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,21 +45,6 @@ config DRM_I915_KMS
If in doubt, say "Y".
-config DRM_I915_FBDEV
- bool "Enable legacy fbdev support for the modesetting intel driver"
- depends on DRM_I915
- select DRM_KMS_FB_HELPER
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev
- support. Note that this support also provide the linux console
- support on top of the intel modesetting driver.
-
- If in doubt, say "Y".
-
config DRM_I915_PRELIMINARY_HW_SUPPORT
bool "Enable preliminary support for prerelease Intel hardware by
default"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f019225..3b3325d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,8 +56,8 @@ i915-y += intel_audio.o \
intel_psr.o \
intel_sideband.o \
intel_sprite.o
-i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
+i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
+i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
# modesetting output/encoder code
i915-y += dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e8b18e5..0c8bcd7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
struct intel_fbdev *ifbdev = NULL;
struct intel_framebuffer *fb;
-#ifdef CONFIG_DRM_I915_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_i915_private *dev_priv = dev->dev_private;
ifbdev = dev_priv->fbdev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..e511fa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1819,11 +1819,9 @@ struct drm_i915_private {
struct drm_i915_gem_object *vlv_pctx;
-#ifdef CONFIG_DRM_I915_FBDEV
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
struct work_struct fbdev_suspend_work;
-#endif
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e730789..9cf13e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
-#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
@@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
return NULL;
return fb;
-#else
- return NULL;
-#endif
}
bool intel_get_load_detect_pipe(struct drm_connector *connector,
@@ -12807,11 +12803,13 @@ intel_user_framebuffer_create(struct drm_device *dev,
return intel_framebuffer_create(dev, mode_cmd, obj);
}
-#ifndef CONFIG_DRM_I915_FBDEV
static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (dev_priv->fbdev)
+ drm_fb_helper_hotplug_event(_priv->fbdev->helper);
}
-#endif
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/driv
[RFC 5/6] drm/imx: Remove local fbdev emulation Kconfig option
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation for
the imx kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION config
option where applicable. Using this config lets us also prevent wrapping around
drm_fb_helper_* calls with #ifdefs in certain places.
We replace the #ifdef in imx_drm_driver_load with CONFIG_DRM_FBDEV_EMULATION.
It's probably okay to get remove the #ifdef itself, but just left it here for
now to be safe. It can be removed after some testing.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/imx/Kconfig| 9 -
drivers/gpu/drm/imx/imx-drm-core.c | 10 +-
2 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 33cdddf..e008960 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -10,15 +10,6 @@ config DRM_IMX
help
enable i.MX graphics support
-config DRM_IMX_FB_HELPER
- tristate "provide legacy framebuffer /dev/fb0"
- select DRM_KMS_CMA_HELPER
- depends on DRM_IMX
- help
- The DRM framework can provide a legacy /dev/fb0 framebuffer
- for your device. This is necessary to get a framebuffer console
- and also for applications using the legacy framebuffer API
-
config DRM_IMX_PARALLEL_DISPLAY
tristate "Support for parallel displays"
select DRM_PANEL
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index a002f53..5cbcb8a 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -60,26 +60,20 @@ EXPORT_SYMBOL_GPL(imx_drm_crtc_id);
static void imx_drm_driver_lastclose(struct drm_device *drm)
{
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm->dev_private;
if (imxdrm->fbhelper)
drm_fbdev_cma_restore_mode(imxdrm->fbhelper);
-#endif
}
static int imx_drm_driver_unload(struct drm_device *drm)
{
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm->dev_private;
-#endif
drm_kms_helper_poll_fini(drm);
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
if (imxdrm->fbhelper)
drm_fbdev_cma_fini(imxdrm->fbhelper);
-#endif
component_unbind_all(drm->dev, drm);
@@ -215,11 +209,9 @@ EXPORT_SYMBOL_GPL(imx_drm_encoder_destroy);
static void imx_drm_output_poll_changed(struct drm_device *drm)
{
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm->dev_private;
drm_fbdev_cma_hotplug_event(imxdrm->fbhelper);
-#endif
}
static struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
@@ -308,7 +300,7 @@ static int imx_drm_driver_load(struct drm_device *drm,
unsigned long flags)
* The fb helper takes copies of key hardware information, so the
* crtcs/connectors/encoders must not change after this point.
*/
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
+#ifdef CONFIG_DRM_FBDEV_EMULATION
if (legacyfb_depth != 16 && legacyfb_depth != 32) {
dev_warn(drm->dev, "Invalid legacyfb_depth. Defaulting to
16bpp\n");
legacyfb_depth = 16;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/6] drm: Add DRM_FBDEV_EMULATION Kconfig option
This provides a uniform interface to enable/disable legacy fbdev support for modesetting drivers, based on the discussion here: http://lists.freedesktop.org/archives/dri-devel/2015-March/078729.html This has only been build-tested for a few devices. Mainly looking for comments for now. The drivers that provide fbdev emulation by default won't be impacted by this. However, if we could make all drivers use DRM_FBDEV_EMULATION, it would clean up individual Kconfigs, and have a centralized place where we touch FB_* configs. Archit Taneja (6): drm: Add top level Kconfig option for DRM fbdev emulation drm/msm: Remove local fbdev emulation Kconfig option drm/i915: Remove local fbdev emulation Kconfig option drm/tegra: Remove local fbdev emulation Kconfig option drm/imx: Remove local fbdev emulation Kconfig option drm/sti: Remove local fbdev emulation Kconfig option drivers/gpu/drm/Kconfig | 18 ++ drivers/gpu/drm/Makefile | 4 ++ drivers/gpu/drm/i915/Kconfig | 15 - drivers/gpu/drm/i915/Makefile| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 2 - drivers/gpu/drm/i915/intel_display.c | 10 ++- drivers/gpu/drm/i915/intel_dp_mst.c | 14 ++-- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_fbdev.c | 7 -- drivers/gpu/drm/imx/Kconfig | 9 --- drivers/gpu/drm/imx/imx-drm-core.c | 10 +-- drivers/gpu/drm/msm/Kconfig | 14 drivers/gpu/drm/msm/Makefile | 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 +- drivers/gpu/drm/sti/Kconfig | 6 -- drivers/gpu/drm/sti/sti_drm_drv.c| 2 +- drivers/gpu/drm/tegra/Kconfig| 12 drivers/gpu/drm/tegra/drm.c | 15 +++-- drivers/gpu/drm/tegra/drm.h | 8 --- drivers/gpu/drm/tegra/fb.c | 25 ++-- include/drm/drm_fb_helper.h | 120 +++ 22 files changed, 179 insertions(+), 127 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by selecting
KMS FB helpers. A few provide a separate Kconfig option for the user to enable
or disbale fbdev emulation.
Enabling fbdev emulation is finally a distro-level decision. Having a top level
Kconfig option for fbdev emulation helps by providing a uniform way to
enable/disable fbdev emulation for any modesetting driver. It also lets us
remove unnecessary driver specific Kconfig options that causes bloat.
With a top level Kconfig in place, we can stub out the fb helper functions when
not needed without breaking functionality. Having stub functions also prevents
drivers to require wrapping fb helper function calls with #ifdefs.
DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
default and majority of distributions expect the fbdev interface in the kernel.
For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
modesetting drivers use the former and other the later. This needs to be taken
care of in a better way.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/Kconfig | 18 +++
drivers/gpu/drm/Makefile| 4 ++
include/drm/drm_fb_helper.h | 120
3 files changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool "Enable legacy fbdev support for your modesetting driver"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
+
config DRM_LOAD_EDID_FIRMWARE
bool "Allow to specify an EDID data set instead of probing for it"
depends on DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..c1d44b2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+
+ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
+endif
+
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 21b944c..dbfce1a 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -103,6 +103,7 @@ struct drm_fb_helper {
bool delayed_hotplug;
};
+#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
const struct drm_fb_helper_funcs *funcs);
int drm_fb_helper_init(struct drm_device *dev,
@@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
*fb_helper_conn,
int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector);
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector);
+#else
+static inline void drm_fb_helper_prepare(struct drm_device *dev,
+ struct drm_fb_helper *helper,
+ const struct drm_fb_helper_funcs *funcs)
+{
+}
+
+static inline int drm_fb_helper_init(struct drm_device *dev,
+ struct drm_fb_helper *helper, int crtc_count,
+ int max_conn)
+{
+ return 0;
+}
+
+static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
+{
+}
+
+static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_set_par(struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ return 0;
+}
+
+static inline bool
+drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_
[RFC 4/6] drm/tegra: Remove local fbdev emulation Kconfig option
DRM_TEGRA_FBDEV config is currently used to enable/disable fbdev emulation for
the tegra kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in tegra_drm struct that adds/removes the terga_fbdev member has been
removed completely. This helps in calling stub drm fb helper functions at not
much
cost.
We could clean up fb.c a bit further to reduce the number of #ifdefs, but that's
left for later.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/tegra/Kconfig | 12
drivers/gpu/drm/tegra/drm.c | 15 ++-
drivers/gpu/drm/tegra/drm.h | 8
drivers/gpu/drm/tegra/fb.c| 25 ++---
4 files changed, 16 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d62..63ebb15 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -16,18 +16,6 @@ config DRM_TEGRA
if DRM_TEGRA
-config DRM_TEGRA_FBDEV
- bool Enable legacy fbdev support
- select DRM_KMS_FB_HELPER
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev support.
- Note that this support also provides the Linux console on top of
- the Tegra modesetting driver.
-
config DRM_TEGRA_DEBUG
bool NVIDIA Tegra DRM debug support
help
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 7dd328d..97ebde9 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -104,11 +104,17 @@ static int tegra_atomic_commit(struct drm_device *drm,
return 0;
}
+static inline void tegra_fb_output_poll_changed(struct drm_device *drm)
+{
+ struct tegra_drm *tegra = drm-dev_private;
+
+ if (tegra-fbdev)
+ drm_fb_helper_hotplug_event(tegra-fbdev-base);
+}
+
static const struct drm_mode_config_funcs tegra_drm_mode_funcs = {
.fb_create = tegra_fb_create,
-#ifdef CONFIG_DRM_TEGRA_FBDEV
.output_poll_changed = tegra_fb_output_poll_changed,
-#endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = tegra_atomic_commit,
};
@@ -248,11 +254,10 @@ static void tegra_drm_context_free(struct
tegra_drm_context *context)
static void tegra_drm_lastclose(struct drm_device *drm)
{
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_drm *tegra = drm-dev_private;
- tegra_fbdev_restore_mode(tegra-fbdev);
-#endif
+ if (tegra-fbdev)
+ drm_fb_helper_restore_fbdev_mode_unlocked(tegra-fbdev-base);
}
static struct host1x_bo *
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 8cb2dfe..3a92413 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -29,12 +29,10 @@ struct tegra_fb {
unsigned int num_planes;
};
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_fbdev {
struct drm_fb_helper base;
struct tegra_fb *fb;
};
-#endif
struct tegra_drm {
struct drm_device *drm;
@@ -45,9 +43,7 @@ struct tegra_drm {
struct mutex clients_lock;
struct list_head clients;
-#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_fbdev *fbdev;
-#endif
unsigned int pitch_align;
@@ -263,10 +259,6 @@ int tegra_drm_fb_prepare(struct drm_device *drm);
void tegra_drm_fb_free(struct drm_device *drm);
int tegra_drm_fb_init(struct drm_device *drm);
void tegra_drm_fb_exit(struct drm_device *drm);
-#ifdef CONFIG_DRM_TEGRA_FBDEV
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
-void tegra_fb_output_poll_changed(struct drm_device *drm);
-#endif
extern struct platform_driver tegra_dc_driver;
extern struct platform_driver tegra_dsi_driver;
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 397fb34..2eacea2 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -18,7 +18,7 @@ static inline struct tegra_fb *to_tegra_fb(struct
drm_framebuffer *fb)
return container_of(fb, struct tegra_fb, base);
}
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
static inline struct tegra_fbdev *to_tegra_fbdev(struct drm_fb_helper *helper)
{
return container_of(helper, struct tegra_fbdev, base);
@@ -181,7 +181,7 @@ unreference:
return ERR_PTR(err);
}
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
static struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
.fb_fillrect = sys_fillrect,
@@ -371,24 +371,11 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
tegra_fbdev_free(fbdev);
}
-void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev)
-{
- if (fbdev)
- drm_fb_helper_restore_fbdev_mode_unlocked(fbdev-base);
-}
-
-void
[RFC 2/6] drm/msm: Remove local fbdev emulation Kconfig option
DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the msm kms driver. Replace this with the top level DRM_FBDEV_EMULATION config option where applicable. This also prevents build breaks caused by undefined drm_fb_helper_* functions when legacy fbdev support was disabled. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/msm/Kconfig | 14 -- drivers/gpu/drm/msm/Makefile | 2 +- drivers/gpu/drm/msm/msm_drv.c | 4 ++-- 3 files changed, 3 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig index bacbbb7..d6f3a4f 100644 --- a/drivers/gpu/drm/msm/Kconfig +++ b/drivers/gpu/drm/msm/Kconfig @@ -13,20 +13,6 @@ config DRM_MSM help DRM/KMS driver for MSM/snapdragon. -config DRM_MSM_FBDEV - bool Enable legacy fbdev support for MSM modesetting driver - depends on DRM_MSM - select DRM_KMS_FB_HELPER - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - default y - help - Choose this option if you have a need for the legacy fbdev - support. Note that this support also provide the linux console - support on top of the MSM modesetting driver. - config DRM_MSM_REGISTER_LOGGING bool MSM DRM register logging depends on DRM_MSM diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index 674a132..40726ad 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -48,7 +48,7 @@ msm-y := \ msm_rd.o \ msm_ringbuffer.o -msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o +msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o obj-$(CONFIG_DRM_MSM) += msm.o diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index a426911..d3e816a 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -54,7 +54,7 @@ module_param(reglog, bool, 0600); #define reglog 0 #endif -#ifdef CONFIG_DRM_MSM_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION static bool fbdev = true; MODULE_PARM_DESC(fbdev, Enable fbdev compat layer); module_param(fbdev, bool, 0600); @@ -305,7 +305,7 @@ static int msm_load(struct drm_device *dev, unsigned long flags) drm_mode_config_reset(dev); -#ifdef CONFIG_DRM_MSM_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION if (fbdev) priv-fbdev = msm_fbdev_init(dev); #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 6/6] drm/sti: Remove local fbdev emulation Kconfig option
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation for the sti kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option instead where applicable. We replace the #ifdef in sti_drm_load with CONFIG_DRM_FBDEV_EMULATION. It's probably okay to get remove the #ifdef itself, but just left it here for now to be safe. It can be removed after some testing. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/sti/Kconfig | 6 -- drivers/gpu/drm/sti/sti_drm_drv.c | 2 +- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index fbccc10..e3aa5af 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -9,9 +9,3 @@ config DRM_STI select FW_LOADER_USER_HELPER_FALLBACK help Choose this option to enable DRM on STM stiH41x chipset - -config DRM_STI_FBDEV - bool DRM frame buffer device for STMicroelectronics SoC stiH41x Serie - depends on DRM_STI - help - Choose this option to enable FBDEV on top of DRM for STM stiH41x chipset diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c b/drivers/gpu/drm/sti/sti_drm_drv.c index 5239fa1..90f121d 100644 --- a/drivers/gpu/drm/sti/sti_drm_drv.c +++ b/drivers/gpu/drm/sti/sti_drm_drv.c @@ -76,7 +76,7 @@ static int sti_drm_load(struct drm_device *dev, unsigned long flags) drm_helper_disable_unused_functions(dev); -#ifdef CONFIG_DRM_STI_FBDEV +#ifdef CONFIG_DRM_FBDEV_EMULATION drm_fbdev_cma_init(dev, 32, dev-mode_config.num_crtc, dev-mode_config.num_connector); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Archit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
the i915 kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
fbdev_suspend_work has been removed. This helps us use stub drm helper functions
at not much cost.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/i915/Kconfig | 15 ---
drivers/gpu/drm/i915/Makefile| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c | 7 ---
8 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9..bd9ccfc 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,21 +45,6 @@ config DRM_I915_KMS
If in doubt, say Y.
-config DRM_I915_FBDEV
- bool Enable legacy fbdev support for the modesetting intel driver
- depends on DRM_I915
- select DRM_KMS_FB_HELPER
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev
- support. Note that this support also provide the linux console
- support on top of the intel modesetting driver.
-
- If in doubt, say Y.
-
config DRM_I915_PRELIMINARY_HW_SUPPORT
bool Enable preliminary support for prerelease Intel hardware by
default
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f019225..3b3325d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,8 +56,8 @@ i915-y += intel_audio.o \
intel_psr.o \
intel_sideband.o \
intel_sprite.o
-i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
+i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
+i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
# modesetting output/encoder code
i915-y += dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e8b18e5..0c8bcd7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
struct intel_fbdev *ifbdev = NULL;
struct intel_framebuffer *fb;
-#ifdef CONFIG_DRM_I915_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_i915_private *dev_priv = dev-dev_private;
ifbdev = dev_priv-fbdev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..e511fa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1819,11 +1819,9 @@ struct drm_i915_private {
struct drm_i915_gem_object *vlv_pctx;
-#ifdef CONFIG_DRM_I915_FBDEV
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
struct work_struct fbdev_suspend_work;
-#endif
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e730789..9cf13e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
-#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
@@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
return NULL;
return fb;
-#else
- return NULL;
-#endif
}
bool intel_get_load_detect_pipe(struct drm_connector *connector,
@@ -12807,11 +12803,13 @@ intel_user_framebuffer_create(struct drm_device *dev,
return intel_framebuffer_create(dev, mode_cmd, obj);
}
-#ifndef CONFIG_DRM_I915_FBDEV
static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-fbdev)
+ drm_fb_helper_hotplug_event(dev_priv-fbdev-helper);
}
-#endif
static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 9f67a37..fe69df0
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. Maybe clarify that for linux console support you also need CONFIG_FRAMEBUFFER_CONSOLE? fbdev alone isn't enough. DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Another option would be to provide #ifdef DRM_FBDEV_EMULATION wrap-arounds for fb related function calls/declarations in each driver, something that's already done for i915 and msm drivers. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/6] drm: Add DRM_FBDEV_EMULATION Kconfig option
This provides a uniform interface to enable/disable legacy fbdev support for modesetting drivers, based on the discussion here: http://lists.freedesktop.org/archives/dri-devel/2015-March/078729.html This has only been build-tested for a few devices. Mainly looking for comments for now. The drivers that provide fbdev emulation by default won't be impacted by this. However, if we could make all drivers use DRM_FBDEV_EMULATION, it would clean up individual Kconfigs, and have a centralized place where we touch FB_* configs. Archit Taneja (6): drm: Add top level Kconfig option for DRM fbdev emulation drm/msm: Remove local fbdev emulation Kconfig option drm/i915: Remove local fbdev emulation Kconfig option drm/tegra: Remove local fbdev emulation Kconfig option drm/imx: Remove local fbdev emulation Kconfig option drm/sti: Remove local fbdev emulation Kconfig option drivers/gpu/drm/Kconfig | 18 ++ drivers/gpu/drm/Makefile | 4 ++ drivers/gpu/drm/i915/Kconfig | 15 - drivers/gpu/drm/i915/Makefile| 4 +- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 2 - drivers/gpu/drm/i915/intel_display.c | 10 ++- drivers/gpu/drm/i915/intel_dp_mst.c | 14 ++-- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_fbdev.c | 7 -- drivers/gpu/drm/imx/Kconfig | 9 --- drivers/gpu/drm/imx/imx-drm-core.c | 10 +-- drivers/gpu/drm/msm/Kconfig | 14 drivers/gpu/drm/msm/Makefile | 2 +- drivers/gpu/drm/msm/msm_drv.c| 4 +- drivers/gpu/drm/sti/Kconfig | 6 -- drivers/gpu/drm/sti/sti_drm_drv.c| 2 +- drivers/gpu/drm/tegra/Kconfig| 12 drivers/gpu/drm/tegra/drm.c | 15 +++-- drivers/gpu/drm/tegra/drm.h | 8 --- drivers/gpu/drm/tegra/fb.c | 25 ++-- include/drm/drm_fb_helper.h | 120 +++ 22 files changed, 179 insertions(+), 127 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by selecting
KMS FB helpers. A few provide a separate Kconfig option for the user to enable
or disbale fbdev emulation.
Enabling fbdev emulation is finally a distro-level decision. Having a top level
Kconfig option for fbdev emulation helps by providing a uniform way to
enable/disable fbdev emulation for any modesetting driver. It also lets us
remove unnecessary driver specific Kconfig options that causes bloat.
With a top level Kconfig in place, we can stub out the fb helper functions when
not needed without breaking functionality. Having stub functions also prevents
drivers to require wrapping fb helper function calls with #ifdefs.
DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by
default and majority of distributions expect the fbdev interface in the kernel.
For now, this config selects both FB_SYS_* and FB_CFB_* configs as some
modesetting drivers use the former and other the later. This needs to be taken
care of in a better way.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/Kconfig | 18 +++
drivers/gpu/drm/Makefile| 4 ++
include/drm/drm_fb_helper.h | 120
3 files changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..38f83a0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER
help
FBDEV helpers for KMS drivers.
+config DRM_FBDEV_EMULATION
+ bool Enable legacy fbdev support for your modesetting driver
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_SYS_FOPS
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ default y
+ help
+ Choose this option if you have a need for the legacy fbdev
+ support. Note that this support also provide the linux console
+ support on top of your modesetting driver.
+
config DRM_LOAD_EDID_FIRMWARE
bool Allow to specify an EDID data set instead of probing for it
depends on DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..c1d44b2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+
+ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y)
drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
+endif
+
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 21b944c..dbfce1a 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -103,6 +103,7 @@ struct drm_fb_helper {
bool delayed_hotplug;
};
+#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
const struct drm_fb_helper_funcs *funcs);
int drm_fb_helper_init(struct drm_device *dev,
@@ -139,4 +140,123 @@ drm_pick_cmdline_mode(struct drm_fb_helper_connector
*fb_helper_conn,
int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct
drm_connector *connector);
int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
struct drm_connector *connector);
+#else
+static inline void drm_fb_helper_prepare(struct drm_device *dev,
+ struct drm_fb_helper *helper,
+ const struct drm_fb_helper_funcs *funcs)
+{
+}
+
+static inline int drm_fb_helper_init(struct drm_device *dev,
+ struct drm_fb_helper *helper, int crtc_count,
+ int max_conn)
+{
+ return 0;
+}
+
+static inline void drm_fb_helper_fini(struct drm_fb_helper *helper)
+{
+}
+
+static inline int drm_fb_helper_blank(int blank, struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_set_par(struct fb_info *info)
+{
+ return 0;
+}
+
+static inline int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ return 0;
+}
+
+static inline bool
+drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper
[RFC 5/6] drm/imx: Remove local fbdev emulation Kconfig option
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation for
the imx kms driver.
Remove this local config option and use the top level DRM_FBDEV_EMULATION config
option where applicable. Using this config lets us also prevent wrapping around
drm_fb_helper_* calls with #ifdefs in certain places.
We replace the #ifdef in imx_drm_driver_load with CONFIG_DRM_FBDEV_EMULATION.
It's probably okay to get remove the #ifdef itself, but just left it here for
now to be safe. It can be removed after some testing.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/imx/Kconfig| 9 -
drivers/gpu/drm/imx/imx-drm-core.c | 10 +-
2 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 33cdddf..e008960 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -10,15 +10,6 @@ config DRM_IMX
help
enable i.MX graphics support
-config DRM_IMX_FB_HELPER
- tristate provide legacy framebuffer /dev/fb0
- select DRM_KMS_CMA_HELPER
- depends on DRM_IMX
- help
- The DRM framework can provide a legacy /dev/fb0 framebuffer
- for your device. This is necessary to get a framebuffer console
- and also for applications using the legacy framebuffer API
-
config DRM_IMX_PARALLEL_DISPLAY
tristate Support for parallel displays
select DRM_PANEL
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index a002f53..5cbcb8a 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -60,26 +60,20 @@ EXPORT_SYMBOL_GPL(imx_drm_crtc_id);
static void imx_drm_driver_lastclose(struct drm_device *drm)
{
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm-dev_private;
if (imxdrm-fbhelper)
drm_fbdev_cma_restore_mode(imxdrm-fbhelper);
-#endif
}
static int imx_drm_driver_unload(struct drm_device *drm)
{
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm-dev_private;
-#endif
drm_kms_helper_poll_fini(drm);
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
if (imxdrm-fbhelper)
drm_fbdev_cma_fini(imxdrm-fbhelper);
-#endif
component_unbind_all(drm-dev, drm);
@@ -215,11 +209,9 @@ EXPORT_SYMBOL_GPL(imx_drm_encoder_destroy);
static void imx_drm_output_poll_changed(struct drm_device *drm)
{
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm-dev_private;
drm_fbdev_cma_hotplug_event(imxdrm-fbhelper);
-#endif
}
static struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
@@ -308,7 +300,7 @@ static int imx_drm_driver_load(struct drm_device *drm,
unsigned long flags)
* The fb helper takes copies of key hardware information, so the
* crtcs/connectors/encoders must not change after this point.
*/
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
+#ifdef CONFIG_DRM_FBDEV_EMULATION
if (legacyfb_depth != 16 legacyfb_depth != 32) {
dev_warn(drm-dev, Invalid legacyfb_depth. Defaulting to
16bpp\n);
legacyfb_depth = 16;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 03:16 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: Legacy fbdev emulation support via DRM is achieved through KMS FB helpers. Most modesetting drivers enable provide fbdev emulation by default by selecting KMS FB helpers. A few provide a separate Kconfig option for the user to enable or disbale fbdev emulation. Enabling fbdev emulation is finally a distro-level decision. Having a top level Kconfig option for fbdev emulation helps by providing a uniform way to enable/disable fbdev emulation for any modesetting driver. It also lets us remove unnecessary driver specific Kconfig options that causes bloat. With a top level Kconfig in place, we can stub out the fb helper functions when not needed without breaking functionality. Having stub functions also prevents drivers to require wrapping fb helper function calls with #ifdefs. DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev emulation by default and majority of distributions expect the fbdev interface in the kernel. For now, this config selects both FB_SYS_* and FB_CFB_* configs as some modesetting drivers use the former and other the later. This needs to be taken care of in a better way. Signed-off-by: Archit Taneja arch...@codeaurora.org --- drivers/gpu/drm/Kconfig | 18 +++ drivers/gpu/drm/Makefile| 4 ++ include/drm/drm_fb_helper.h | 120 3 files changed, 142 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 151a050..38f83a0 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -40,6 +40,24 @@ config DRM_KMS_FB_HELPER help FBDEV helpers for KMS drivers. +config DRM_FBDEV_EMULATION + bool Enable legacy fbdev support for your modesetting driver + depends on DRM + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select FB_SYS_FILLRECT + select FB_SYS_COPYAREA + select FB_SYS_IMAGEBLIT + select FB_SYS_FOPS + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + default y + help + Choose this option if you have a need for the legacy fbdev + support. Note that this support also provide the linux console + support on top of your modesetting driver. + config DRM_LOAD_EDID_FIRMWARE bool Allow to specify an EDID data set instead of probing for it depends on DRM_KMS_HELPER diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c239b9..c1d44b2 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -25,7 +25,11 @@ drm-$(CONFIG_OF) += drm_of.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o + +ifeq ($(CONFIG_DRM_FBDEV_EMULATION),y) drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o +endif This should work as drm_kms_helper-$CONFIG_DRM_FBDEV_EMULATION += drm_fb_helper.o since both modename-y and modename-m are merged together. Ah right. I'll fix that. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
On 03/10/2015 03:31 PM, Daniel Vetter wrote:
On Tue, Mar 10, 2015 at 03:11:30PM +0530, Archit Taneja wrote:
DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
the i915 kms driver.
Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
in certain places.
The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
fbdev_suspend_work has been removed. This helps us use stub drm helper functions
at not much cost.
Signed-off-by: Archit Taneja arch...@codeaurora.org
---
drivers/gpu/drm/i915/Kconfig | 15 ---
drivers/gpu/drm/i915/Makefile| 4 ++--
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/intel_display.c | 10 --
drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c | 7 ---
8 files changed, 16 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9..bd9ccfc 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -45,21 +45,6 @@ config DRM_I915_KMS
If in doubt, say Y.
-config DRM_I915_FBDEV
- bool Enable legacy fbdev support for the modesetting intel driver
- depends on DRM_I915
- select DRM_KMS_FB_HELPER
- select FB_CFB_FILLRECT
- select FB_CFB_COPYAREA
- select FB_CFB_IMAGEBLIT
- default y
- help
- Choose this option if you have a need for the legacy fbdev
- support. Note that this support also provide the linux console
- support on top of the intel modesetting driver.
-
- If in doubt, say Y.
-
config DRM_I915_PRELIMINARY_HW_SUPPORT
bool Enable preliminary support for prerelease Intel hardware by
default
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f019225..3b3325d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,8 +56,8 @@ i915-y += intel_audio.o \
intel_psr.o \
intel_sideband.o \
intel_sprite.o
-i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
-i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
+i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
+i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
# modesetting output/encoder code
i915-y += dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e8b18e5..0c8bcd7 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
struct intel_fbdev *ifbdev = NULL;
struct intel_framebuffer *fb;
-#ifdef CONFIG_DRM_I915_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct drm_i915_private *dev_priv = dev-dev_private;
ifbdev = dev_priv-fbdev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..e511fa4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1819,11 +1819,9 @@ struct drm_i915_private {
struct drm_i915_gem_object *vlv_pctx;
-#ifdef CONFIG_DRM_I915_FBDEV
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
struct work_struct fbdev_suspend_work;
-#endif
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e730789..9cf13e6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
mode_fits_in_fbdev(struct drm_device *dev,
struct drm_display_mode *mode)
{
-#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
struct drm_framebuffer *fb;
@@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
return NULL;
return fb;
-#else
- return NULL;
-#endif
Won't this now blow up if there's no fbdev? Tbh I prefer a patch to just
replace the CONFIG_ #define and then maybe a 2nd one on top to clean
things up if you feel like. Same for the other changes in this patch.
There are checks for dev_priv-fbdev and dev_priv-fbdev-fb being non
NULL at the start of the function which would prevent that. But you're
right, the first patch for each device can replace the config, the later
ones can take advantage of the stub functions.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation
On 03/10/2015 09:03 PM, Jani Nikula wrote: On Tue, 10 Mar 2015, Archit Taneja arch...@codeaurora.org wrote: On 03/10/2015 03:35 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote: On 03/10/2015 03:17 PM, Daniel Vetter wrote: On Tue, Mar 10, 2015 at 03:11:28PM +0530, Archit Taneja wrote: DRM_KMS_FB_HELPER selects that for us, right? Hm right I've missed that. Reminds me that you need one more patch at the end to remove all the various select DRM_KMS_FB_HELPER from all drm drivers. Otherwise this knob here won't work by default if you e.g. select radeon. In general we can't mix explicit options with menu entries with a select. I was trying that out. Removing DRM_KMS_FB_HELPER and having DRM_FBDEV_EMULATION disabled breaks drivers which use FB stuff internally in their respective xyz_fbdev.c files. Are you saying that we should remove DRM_KMS_FB_HELPER for such drivers and replace them with 'select DRM_FBDEV_EMULATION'? Slightly tangential: As a rule of thumb, you should not select anything that is visible in menuconfig or has dependencies [1]. This will break the build eventually, and attempts to fix it are troublesome [2]. Thanks, I'll keep this in mind! Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 5/6] drm/imx: Remove local fbdev emulation Kconfig option
On 03/10/2015 04:24 PM, Philipp Zabel wrote: Hi Archit, thanks for the cleanup! Am Dienstag, den 10.03.2015, 15:11 +0530 schrieb Archit Taneja: DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation for the imx kms driver. Remove this local config option and use the top level DRM_FBDEV_EMULATION config option where applicable. Using this config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs in certain places. We replace the #ifdef in imx_drm_driver_load with CONFIG_DRM_FBDEV_EMULATION. It's probably okay to get remove the #ifdef itself, but just left it here for now to be safe. It can be removed after some testing. Signed-off-by: Archit Taneja arch...@codeaurora.org Tested-by: Philipp Zabel p.za...@pengutronix.de (Both with and without the #ifdef CONFIG_DRM_FBDEV_EMULATION removed.) Thanks for testing it out. Although this is for another patch, I think the legacyfb_depth module_param should be removed altogether if CONFIG_DRM_FBDEV_EMULATION is disabled, so maybe that #ifdef should stay. I'll create a patch for that for future revs of this patch set. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
On 03/09/2015 01:14 PM, Daniel Vetter wrote: On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote: On 03/05/2015 09:14 PM, Daniel Vetter wrote: On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote: On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja wrote: On 02/23/2015 09:09 PM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: Rather than creating fb helper stub functions, maybe we could help each drm driver create two variants of functions needed by drm core(like output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, and the other not? So one quick thought.. building without fbdev would ideally/eventually be a distro level decision, not a driver level decision.. so I think it is *eventually* not a problem for it being a global drm level decision. The only problem is right now some drivers support no-fbdev config, and some do not. Maybe it is worth fixing that? Yeah, if we get fbdev emulation Kconfig option then I think i915 and msm should remove their own options and just use that. There's really no need to have this per-driver, this is a question of what userspace expects and so per-distro, independant of the driver. -Daniel Okay. If I understand right. We need to do something like this: - Create a new Kconfig option that lets us emulate fbdev - For drivers that already have a config for fbdev emulation, replace it with our new emulation config. - For drivers that assume fbdev emulation by default, select our new emulation config in their respective Kconfigs. Does this sound okay? I suppose this could be the first step. Later we'd need to work on each driver to work with and without the fbdev emulation Kconfig option. See Rob's idea quoted above: Imo you should just do the conditional code in the fbdev emulation helper in drm_fb_helper.c, not in drivers. There's some additional code in i915 (and maybe also msm) to compile out (mostly around taking/dropping console_lock) and we want to keep that. But that should also just be using the same new config option. So: - Add new config option DRM_FBDEV_EMULATION (default y for backwards compat). Use that to stub out helpers in drm_fb_helper.c. - Replace the msm/i915 specific options with the new, i.e. remove it from Kconfig and use DRM_FBDEV_EMULATION in the code instead of the msm/i915 specific one. fbdev-less support for all other drivers will just magically happen without the need for driver-specific code (except for the special locking in i915 and similar things maybe). That sounds good. I wasn't totally sure about fbdev-less support working out of the box on devices that use the fb CMA helpers. The drm_fbdev_cma_* funcs internally use the fb helper functions. Stubbing the fb helpers out might result in some corner cases. However, after a quick look at that the cma helpers, it looks like it take all the necessary precautions to prevent uninitialized accesses. Although, it would be ideal to stub out the drm_fbdev_cma_* helper functions too since they don't serve any purpose when fbdev emulation is disabled. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
On 03/09/2015 01:14 PM, Daniel Vetter wrote: On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote: On 03/05/2015 09:14 PM, Daniel Vetter wrote: On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote: On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja arch...@codeaurora.org wrote: On 02/23/2015 09:09 PM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: Rather than creating fb helper stub functions, maybe we could help each drm driver create two variants of functions needed by drm core(like output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, and the other not? So one quick thought.. building without fbdev would ideally/eventually be a distro level decision, not a driver level decision.. so I think it is *eventually* not a problem for it being a global drm level decision. The only problem is right now some drivers support no-fbdev config, and some do not. Maybe it is worth fixing that? Yeah, if we get fbdev emulation Kconfig option then I think i915 and msm should remove their own options and just use that. There's really no need to have this per-driver, this is a question of what userspace expects and so per-distro, independant of the driver. -Daniel Okay. If I understand right. We need to do something like this: - Create a new Kconfig option that lets us emulate fbdev - For drivers that already have a config for fbdev emulation, replace it with our new emulation config. - For drivers that assume fbdev emulation by default, select our new emulation config in their respective Kconfigs. Does this sound okay? I suppose this could be the first step. Later we'd need to work on each driver to work with and without the fbdev emulation Kconfig option. See Rob's idea quoted above: Imo you should just do the conditional code in the fbdev emulation helper in drm_fb_helper.c, not in drivers. There's some additional code in i915 (and maybe also msm) to compile out (mostly around taking/dropping console_lock) and we want to keep that. But that should also just be using the same new config option. So: - Add new config option DRM_FBDEV_EMULATION (default y for backwards compat). Use that to stub out helpers in drm_fb_helper.c. - Replace the msm/i915 specific options with the new, i.e. remove it from Kconfig and use DRM_FBDEV_EMULATION in the code instead of the msm/i915 specific one. fbdev-less support for all other drivers will just magically happen without the need for driver-specific code (except for the special locking in i915 and similar things maybe). That sounds good. I wasn't totally sure about fbdev-less support working out of the box on devices that use the fb CMA helpers. The drm_fbdev_cma_* funcs internally use the fb helper functions. Stubbing the fb helpers out might result in some corner cases. However, after a quick look at that the cma helpers, it looks like it take all the necessary precautions to prevent uninitialized accesses. Although, it would be ideal to stub out the drm_fbdev_cma_* helper functions too since they don't serve any purpose when fbdev emulation is disabled. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
On 03/05/2015 09:14 PM, Daniel Vetter wrote: On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote: On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja wrote: On 02/23/2015 09:09 PM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja wrote: The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev support is disabled in msm. Wrap around these functions with #ifdef checks to prevent build break. hmm, perhaps rather than solving this in each driver, we should do some stub versions of those fb-helper fxns? There are at least one or two other drivers that can build without fbdev, and I guess more going forward.. It's not quite that easy since you also have to start/stop the vt subsystem at the right point in time in your own driver. See intel_fbdev_set_suspend. If you don't do that there's no synchronization between fbcon shutting down/resuming and your driver, which in the best case means fbcon does some writes to nowhere and worst case means your chip dies (mmio to offline chip blocks) or writes go to somewhere random in system memory (iommu contains some stale ptes since not yet fully restored, more an issue with hibernate). I guess I don't fully follow the vt/fbcon interaction if there is no fbdev driver... but then again I don't have vesafb/efifb to contend with, so I'm assuming something to do with that.. It's the other way round: There's interaction when we have fbdev enabled beyond just calling a few fbdev helper functions. And we should compile that out too since the console_lock is way too evil ;-) Only with these additional #ifdefs is i915 completely console_lock free if you disable i915 fbdev support. Just stubbing out the fbdev helper functions is not enough. And because the console_lock is massively contended we do that in a async worker in i915. But anyway I agree it would still simply drivers quite a bit if we'd have support for dummy fb helpers in the core, maybe with an explicit Kconfig. Then drivers could switch to using that for the additional #ifdef (like the vt stuff i915 does) and otherwise rely upon dummy static inline. That would give us fbdev-less support for most drivers for free, which is kinda neat. I guess at least for all the arm drivers, life without fbdev doesn't have these extra complications, so at least they could use stubs.. Does the problem sound more tricky with the above clarification? If you don't do the fb_set_suspend call then I expect you'll have some interesting problems. Plus, I kind of expect phone/tablet/chromebook type stuff would lead the charge into an fbdev-less world.. Yeah, that's another reason to support fbdev-less in the helpers instead of each driver. I was trying to create a patch with the idea above. This works well if we want the kernel to support only one DRM driver. If the kernel supports multiple platforms and one DRM driver sets its config to enable legacy fbdev and another doesn't, we still end up building the fbdev helper funcs. Drivers built without legacy fbdev would need to be very strict(check for priv->fbdev not NULL) to prevent calling them. The fb cma helper also adds to the difficulties. The cma helper seems to have some functions that provide legacy fbdev support and others that allow allocation of drm_framebuffers and gem objects. We'd need to be careful about our stub functions not messing up the drivers using the fb cma helpers. Rather than creating fb helper stub functions, maybe we could help each drm driver create two variants of functions needed by drm core(like output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, and the other not? So one quick thought.. building without fbdev would ideally/eventually be a distro level decision, not a driver level decision.. so I think it is *eventually* not a problem for it being a global drm level decision. The only problem is right now some drivers support no-fbdev config, and some do not. Maybe it is worth fixing that? Yeah, if we get fbdev emulation Kconfig option then I think i915 and msm should remove their own options and just use that. There's really no need to have this per-driver, this is a question of what userspace expects and so per-distro, independant of the driver. -Daniel Okay. If I understand right. We need to do something like this: - Create a new Kconfig option that lets us emulate fbdev - For drivers that already have a config for fbdev emulation, replace it with our new emulation config. - For drivers that assume fbdev emulation by default, select our new emulation config in their respective Kconfigs. Does this sound okay? I suppose this could be the first step. Later we'd need to work on e
Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
On 03/05/2015 09:14 PM, Daniel Vetter wrote: On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote: On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja arch...@codeaurora.org wrote: On 02/23/2015 09:09 PM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja arch...@codeaurora.org wrote: The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev support is disabled in msm. Wrap around these functions with #ifdef checks to prevent build break. hmm, perhaps rather than solving this in each driver, we should do some stub versions of those fb-helper fxns? There are at least one or two other drivers that can build without fbdev, and I guess more going forward.. It's not quite that easy since you also have to start/stop the vt subsystem at the right point in time in your own driver. See intel_fbdev_set_suspend. If you don't do that there's no synchronization between fbcon shutting down/resuming and your driver, which in the best case means fbcon does some writes to nowhere and worst case means your chip dies (mmio to offline chip blocks) or writes go to somewhere random in system memory (iommu contains some stale ptes since not yet fully restored, more an issue with hibernate). I guess I don't fully follow the vt/fbcon interaction if there is no fbdev driver... but then again I don't have vesafb/efifb to contend with, so I'm assuming something to do with that.. It's the other way round: There's interaction when we have fbdev enabled beyond just calling a few fbdev helper functions. And we should compile that out too since the console_lock is way too evil ;-) Only with these additional #ifdefs is i915 completely console_lock free if you disable i915 fbdev support. Just stubbing out the fbdev helper functions is not enough. And because the console_lock is massively contended we do that in a async worker in i915. But anyway I agree it would still simply drivers quite a bit if we'd have support for dummy fb helpers in the core, maybe with an explicit Kconfig. Then drivers could switch to using that for the additional #ifdef (like the vt stuff i915 does) and otherwise rely upon dummy static inline. That would give us fbdev-less support for most drivers for free, which is kinda neat. I guess at least for all the arm drivers, life without fbdev doesn't have these extra complications, so at least they could use stubs.. Does the problem sound more tricky with the above clarification? If you don't do the fb_set_suspend call then I expect you'll have some interesting problems. Plus, I kind of expect phone/tablet/chromebook type stuff would lead the charge into an fbdev-less world.. Yeah, that's another reason to support fbdev-less in the helpers instead of each driver. I was trying to create a patch with the idea above. This works well if we want the kernel to support only one DRM driver. If the kernel supports multiple platforms and one DRM driver sets its config to enable legacy fbdev and another doesn't, we still end up building the fbdev helper funcs. Drivers built without legacy fbdev would need to be very strict(check for priv-fbdev not NULL) to prevent calling them. The fb cma helper also adds to the difficulties. The cma helper seems to have some functions that provide legacy fbdev support and others that allow allocation of drm_framebuffers and gem objects. We'd need to be careful about our stub functions not messing up the drivers using the fb cma helpers. Rather than creating fb helper stub functions, maybe we could help each drm driver create two variants of functions needed by drm core(like output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, and the other not? So one quick thought.. building without fbdev would ideally/eventually be a distro level decision, not a driver level decision.. so I think it is *eventually* not a problem for it being a global drm level decision. The only problem is right now some drivers support no-fbdev config, and some do not. Maybe it is worth fixing that? Yeah, if we get fbdev emulation Kconfig option then I think i915 and msm should remove their own options and just use that. There's really no need to have this per-driver, this is a question of what userspace expects and so per-distro, independant of the driver. -Daniel Okay. If I understand right. We need to do something like this: - Create a new Kconfig option that lets us emulate fbdev - For drivers that already have a config for fbdev emulation, replace it with our new emulation config. - For drivers that assume fbdev emulation by default, select our new emulation config in their respective Kconfigs. Does this sound okay? I suppose
Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
On 02/23/2015 09:09 PM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja wrote: The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev support is disabled in msm. Wrap around these functions with #ifdef checks to prevent build break. hmm, perhaps rather than solving this in each driver, we should do some stub versions of those fb-helper fxns? There are at least one or two other drivers that can build without fbdev, and I guess more going forward.. It's not quite that easy since you also have to start/stop the vt subsystem at the right point in time in your own driver. See intel_fbdev_set_suspend. If you don't do that there's no synchronization between fbcon shutting down/resuming and your driver, which in the best case means fbcon does some writes to nowhere and worst case means your chip dies (mmio to offline chip blocks) or writes go to somewhere random in system memory (iommu contains some stale ptes since not yet fully restored, more an issue with hibernate). I guess I don't fully follow the vt/fbcon interaction if there is no fbdev driver... but then again I don't have vesafb/efifb to contend with, so I'm assuming something to do with that.. It's the other way round: There's interaction when we have fbdev enabled beyond just calling a few fbdev helper functions. And we should compile that out too since the console_lock is way too evil ;-) Only with these additional #ifdefs is i915 completely console_lock free if you disable i915 fbdev support. Just stubbing out the fbdev helper functions is not enough. And because the console_lock is massively contended we do that in a async worker in i915. But anyway I agree it would still simply drivers quite a bit if we'd have support for dummy fb helpers in the core, maybe with an explicit Kconfig. Then drivers could switch to using that for the additional #ifdef (like the vt stuff i915 does) and otherwise rely upon dummy static inline. That would give us fbdev-less support for most drivers for free, which is kinda neat. I guess at least for all the arm drivers, life without fbdev doesn't have these extra complications, so at least they could use stubs.. Does the problem sound more tricky with the above clarification? If you don't do the fb_set_suspend call then I expect you'll have some interesting problems. Plus, I kind of expect phone/tablet/chromebook type stuff would lead the charge into an fbdev-less world.. Yeah, that's another reason to support fbdev-less in the helpers instead of each driver. I was trying to create a patch with the idea above. This works well if we want the kernel to support only one DRM driver. If the kernel supports multiple platforms and one DRM driver sets its config to enable legacy fbdev and another doesn't, we still end up building the fbdev helper funcs. Drivers built without legacy fbdev would need to be very strict(check for priv->fbdev not NULL) to prevent calling them. The fb cma helper also adds to the difficulties. The cma helper seems to have some functions that provide legacy fbdev support and others that allow allocation of drm_framebuffers and gem objects. We'd need to be careful about our stub functions not messing up the drivers using the fb cma helpers. Rather than creating fb helper stub functions, maybe we could help each drm driver create two variants of functions needed by drm core(like output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, and the other not? Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
On 02/23/2015 09:09 PM, Daniel Vetter wrote: On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 9:09 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Feb 23, 2015 at 08:33:36AM -0500, Rob Clark wrote: On Mon, Feb 23, 2015 at 5:29 AM, Archit Taneja arch...@codeaurora.org wrote: The DRM_KMS_FB_HELPER config is selected only when DRM_MSM_FBDEV config is selected. The driver accesses drm_fb_helper_* functions even when legacy fbdev support is disabled in msm. Wrap around these functions with #ifdef checks to prevent build break. hmm, perhaps rather than solving this in each driver, we should do some stub versions of those fb-helper fxns? There are at least one or two other drivers that can build without fbdev, and I guess more going forward.. It's not quite that easy since you also have to start/stop the vt subsystem at the right point in time in your own driver. See intel_fbdev_set_suspend. If you don't do that there's no synchronization between fbcon shutting down/resuming and your driver, which in the best case means fbcon does some writes to nowhere and worst case means your chip dies (mmio to offline chip blocks) or writes go to somewhere random in system memory (iommu contains some stale ptes since not yet fully restored, more an issue with hibernate). I guess I don't fully follow the vt/fbcon interaction if there is no fbdev driver... but then again I don't have vesafb/efifb to contend with, so I'm assuming something to do with that.. It's the other way round: There's interaction when we have fbdev enabled beyond just calling a few fbdev helper functions. And we should compile that out too since the console_lock is way too evil ;-) Only with these additional #ifdefs is i915 completely console_lock free if you disable i915 fbdev support. Just stubbing out the fbdev helper functions is not enough. And because the console_lock is massively contended we do that in a async worker in i915. But anyway I agree it would still simply drivers quite a bit if we'd have support for dummy fb helpers in the core, maybe with an explicit Kconfig. Then drivers could switch to using that for the additional #ifdef (like the vt stuff i915 does) and otherwise rely upon dummy static inline. That would give us fbdev-less support for most drivers for free, which is kinda neat. I guess at least for all the arm drivers, life without fbdev doesn't have these extra complications, so at least they could use stubs.. Does the problem sound more tricky with the above clarification? If you don't do the fb_set_suspend call then I expect you'll have some interesting problems. Plus, I kind of expect phone/tablet/chromebook type stuff would lead the charge into an fbdev-less world.. Yeah, that's another reason to support fbdev-less in the helpers instead of each driver. I was trying to create a patch with the idea above. This works well if we want the kernel to support only one DRM driver. If the kernel supports multiple platforms and one DRM driver sets its config to enable legacy fbdev and another doesn't, we still end up building the fbdev helper funcs. Drivers built without legacy fbdev would need to be very strict(check for priv-fbdev not NULL) to prevent calling them. The fb cma helper also adds to the difficulties. The cma helper seems to have some functions that provide legacy fbdev support and others that allow allocation of drm_framebuffers and gem objects. We'd need to be careful about our stub functions not messing up the drivers using the fb cma helpers. Rather than creating fb helper stub functions, maybe we could help each drm driver create two variants of functions needed by drm core(like output_poll_changed and dev_lastclose), one variant supporting legacy fbdev, and the other not? Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] drm/msm/mdp5: Make the intf connection in config module
On 03/04/2015 09:14 PM, "Stéphane Viau" wrote:
Hi,
Hi Archit,
On 03/04/2015 12:06 AM, Stephane Viau wrote:
Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 8 +++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h | 4 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 111
++--
3 files changed, 74 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 72c075a..8bee023 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -62,6 +62,10 @@ const struct mdp5_cfg_hw msm8x74_config = {
.count = 4,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
},
+ .intfs = {
+ [0] = INTF_eDP,
+ [3] = INTF_HDMI,
+ },
.max_clk = 2,
};
@@ -111,6 +115,10 @@ const struct mdp5_cfg_hw apq8084_config = {
.count = 5,
.base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
},
+ .intfs = {
+ [0] = INTF_eDP,
+ [3] = INTF_HDMI,
+ },
.max_clk = 32000,
};
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index be149b3..4e91f14 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -58,6 +58,8 @@ struct mdp5_smp_block {
int reserved[MAX_CLIENTS]; /* # of MMBs allocated per client */
};
+#define MDP5_INTF_NUM_MAX 5
+
struct mdp5_cfg_hw {
char *name;
@@ -71,6 +73,8 @@ struct mdp5_cfg_hw {
struct mdp5_sub_block ad;
struct mdp5_sub_block intf;
+ u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
+
The array type could be "enum mdp5_intf_type" rather than u32.
The problem here is that mdp5_cfg.h must be included before mdp5.xml.h
(see mdp5_kms.h #24) so that mdp5_cfg pointer can be resolved in the
latter.
mdp5_cfg.h hence cannot use any types defined in mdp5.xml.h, including
'enum mdp5_intf_type'.
Ah okay.
uint32_t max_clk;
};
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 390d9d2..8cec00e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -161,6 +161,44 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
return 0;
}
+static int construct_encoder(struct mdp5_kms *mdp5_kms,
+ enum mdp5_intf_type intf_type, int intf_num)
+{
+ struct drm_device *dev = mdp5_kms->dev;
+ struct msm_drm_private *priv = dev->dev_private;
+ struct drm_encoder *encoder;
+ struct mdp5_interface intf = {
+ .num= intf_num,
+ .type = intf_type,
+ .mode = MDP5_INTF_MODE_NONE,
+ };
+ int ret = 0;
+
+ encoder = mdp5_encoder_init(dev, );
+ if (IS_ERR(encoder)) {
+ ret = PTR_ERR(encoder);
+ dev_err(dev->dev, "failed to construct encoder: %d\n", ret);
+ return ret;
+ }
+
+ encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
+ priv->encoders[priv->num_encoders++] = encoder;
+
+ if (intf_type == INTF_HDMI) {
+ ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
+ if (ret)
+ dev_err(dev->dev, "failed to init HDMI: %d\n", ret);
+
+ } else if (intf_type == INTF_eDP) {
+ /* Construct bridge/connector for eDP: */
+ ret = msm_edp_modeset_init(priv->edp, dev, encoder);
+ if (ret)
+ dev_err(dev->dev, "failed to init eDP: %d\n", ret);
+ }
+
+ return ret;
+}
+
static int modeset_init(struct mdp5_kms *mdp5_kms)
{
static const enum mdp5_pipe crtcs[] = {
@@ -171,7 +209,6 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
};
struct drm_device *dev = mdp5_kms->dev;
struct msm_drm_private *priv = dev->dev_private;
- struct drm_encoder *encoder;
const struct mdp5_cfg_hw *hw_cfg;
int i, ret;
@@ -222,56 +259,29 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
}
}
- if (priv->hdmi) {
- struct mdp5_interface intf = {
- .num= 3,
- .type = INTF_HDMI,
- .mode = MDP5_INTF_MODE_NONE,
- };
-
- /* Construct encoder for HDMI: */
- encoder = mdp5_encoder_init(dev, );
- if (IS_ERR(encoder)) {
- dev_err(dev->dev, "failed to construct encoder\n");
-
Re: [PATCH v2] clk: qcom: Add MSM8916 Global Clock Controller support
On 02/25/2015 10:14 PM, Georgi Djakov wrote: This patch adds support for the global clock controller found on the MSM8916 based devices. It allows the various device drivers to probe and control their clocks and resets. Signed-off-by: Georgi Djakov --- Changes since v1: * Addressed comments from Stephen Boyd and Archit Taneja * Fixed some incorrect offsets, parents etc. * Driver is tested on MSM8916-MTP device. For MDSS clocks: Tested-by: Archit Taneja Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
