Re: [PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341
Hi dillon min > > okay, thanks alexandre, i will go through these docs. currently i'm on may > day holiday, will be back at next wensday. > after go back to work. i will separate this patch to five part with 9 > patchs , should be more clear > > dts releated > 1, ARM: dts: stm32: Add i2c3 node for stm32f429 > 2, ARM: dts: stm32: Add drm panel ili9341 nodes connect to ldtc > support for stm32f429-disco board > 3, ARM: dts: stm32: Add stmpe811 touch screen support for > stm32f429-disco board > 4, ARM: dts: stm32: Add l3gd20 gyroscope sensor support for > stm32f429-disco board > > clk releated > 1, clk: stm32: Fix ltdc loading hang in set clk rate, pll_hw set to > clks[PLL_VCO_SAI] but not clks[PLL_SAI] > 2, clk: stm32: Add CLK_IGNORE_UNUSED flags for ltdc, make sure ltdc clk > not be released after system startup > > spi releated > 1, spi: stm32: Add transfer mode SPI_SIMPLE_RX, SPI_3WIRE_RX support > for stm32f4 > > drm releated > 1, drm/panel: Add panel driver ilitek-ili9341 > > doc releated > 1, dt-bindings: display: panel: Add binding document for Ilitek Ili9341 Patch separation looks good. Please cc: me on both the binding and the panel patches. The binding must be in DT Schema format (.yaml). See a lot of examples in drm-misc-next for inspiration. Looks forward to see/review your submission. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm v2 1/5] mm/hmm: make CONFIG_DEVICE_PRIVATE into a select
On 2020-05-01 11:20, Jason Gunthorpe wrote: From: Jason Gunthorpe There is no reason for a user to select this or not directly - it should be selected by drivers that are going to use the feature, similar to how CONFIG_HMM_MIRROR works. Yes, this is a nice touch. Reviewed-by: John Hubbard thanks, -- John Hubbard NVIDIA Currently all drivers provide a feature kconfig that will disable use of DEVICE_PRIVATE in that driver, allowing users to avoid enabling this if they don't want the overhead. Acked-by: Felix Kuehling Reviewed-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe --- arch/powerpc/Kconfig| 2 +- drivers/gpu/drm/nouveau/Kconfig | 2 +- mm/Kconfig | 7 +-- 3 files changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 924c541a926008..8de52aefdc74cc 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -455,7 +455,7 @@ config PPC_TRANSACTIONAL_MEM config PPC_UV bool "Ultravisor support" depends on KVM_BOOK3S_HV_POSSIBLE - depends on DEVICE_PRIVATE + select DEVICE_PRIVATE default n help This option paravirtualizes the kernel to run in POWER platforms that diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index d6e4ae1ef7053a..af5793f3e7c2cf 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -86,10 +86,10 @@ config DRM_NOUVEAU_BACKLIGHT config DRM_NOUVEAU_SVM bool "(EXPERIMENTAL) Enable SVM (Shared Virtual Memory) support" - depends on DEVICE_PRIVATE depends on DRM_NOUVEAU depends on MMU depends on STAGING + select DEVICE_PRIVATE select HMM_MIRROR select MMU_NOTIFIER default n diff --git a/mm/Kconfig b/mm/Kconfig index c1acc34c1c358c..7ca36bf5f5058e 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -805,15 +805,10 @@ config HMM_MIRROR depends on MMU config DEVICE_PRIVATE - bool "Unaddressable device memory (GPU memory, ...)" + bool depends on ZONE_DEVICE select DEV_PAGEMAP_OPS - help - Allows creation of struct pages to represent unaddressable device - memory; i.e., memory that is only accessible from the device (or - group of devices). You likely also want to select HMM_MIRROR. - config FRAME_VECTOR bool ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月1日 週五 下午10:59寫道：
>
> Hi Chun-Kuang,
>
> Thank you for your review.
>
> On 1/5/20 16:26, Chun-Kuang Hu wrote:
> > Hi, Enric:
> >
> > Enric Balletbo i Serra 於 2020年4月17日 週五
> > 下午11:06寫道：
> >>
> >> Use the drm_bridge_connector helper to create a connector for pipelines
> >> that use drm_bridge. This allows splitting connector operations across
> >> multiple bridges when necessary, instead of having the last bridge in
> >> the chain creating the connector and handling all connector operations
> >> internally.
> >>
> >> Signed-off-by: Enric Balletbo i Serra
> >> ---
> >>
> >> Changes in v3:
> >> - Move the bridge.type line to the patch that adds drm_bridge support.
> >> (Laurent Pinchart)
> >>
> >> Changes in v2: None
> >>
> >> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
> >> 1 file changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> >> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >> index 157097c63b23..85f76b01ae4d 100644
> >> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> >> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> >> @@ -17,6 +17,7 @@
> >>
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -183,6 +184,7 @@ struct mtk_dsi {
> >> struct drm_encoder encoder;
> >> struct drm_bridge bridge;
> >> struct drm_bridge *next_bridge;
> >> + struct drm_connector *connector;
> >> struct phy *phy;
> >>
> >> void __iomem *regs;
> >> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device
> >> *drm, struct mtk_dsi *dsi)
> >> */
> >> dsi->encoder.possible_crtcs = 1;
> >>
> >> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
> >> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> >> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >> if (ret)
> >> goto err_cleanup_encoder;
> >>
> >> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> >> + if (IS_ERR(dsi->connector)) {
> >> + DRM_ERROR("Unable to create bridge connector\n");
> >> + ret = PTR_ERR(dsi->connector);
> >> + goto err_cleanup_encoder;
> >> + }
> >> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> >> +
> >
> > I'm not very clear about how brige-connector works, but why connector
> > does not attach to panel?
> >
>
> Laurent or other drm maintainers might have more details than me, but, AFAIK
> the
> drm_bridge_connector_init initializes a connector for a chain of bridges that
> starts at the @encoder. At this point you don't know which bridge is connected
> to the panel physically but doesn't really matter as what you know is that
> will
> be only one connector in the chain.
I think the panel is wrapped into next_bridge here,
if (panel) {
dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel);
so the next_bridge is a panel_bridge, in its attach function
panel_bridge_attach(),
according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist,
it would create connector and attach connector to panel.
I'm not sure this flag would exist or not, but for both case, it's strange.
If exist, you create connector in this patch but no where to attach
connector to panel.
If not exist, the next_brige would create one connector and this brige
would create another connector.
I think in your case, mtk_dsi does not directly connect to a panel, so
I need a exact explain. Or someone could test this on a
directly-connect-panel platform.
Regards,
Chun-Kuang.
>
> Thanks,
> Enric
>
> > Regards,
> > Chun-Kuang.
> >
> >> return 0;
> >>
> >> err_cleanup_encoder:
> >> --
> >> 2.25.1
> >>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月1日 週五 下午11:23寫道：
>
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named next_bridge.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Laurent Pinchart
> Acked-by: Sam Ravnborg
> ---
>
> Changes in v4: None
> Changes in v3:
> - Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index cfa45d6abd74..37b8d7ffd835 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -182,7 +182,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_connector conn;
> struct drm_panel *panel;
> - struct drm_bridge *bridge;
> + struct drm_bridge *next_bridge;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -902,9 +902,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device
> *drm, struct mtk_dsi *dsi)
> */
> dsi->encoder.possible_crtcs = 1;
>
> - /* If there's a bridge, attach to it and let it create the connector
> */
> - if (dsi->bridge) {
> - ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL, 0);
> + /* If there's a next bridge, attach to it and let it create the
> connector */
> + if (dsi->next_bridge) {
> + ret = drm_bridge_attach(&dsi->encoder, dsi->next_bridge, NULL,
> + 0);
> if (ret) {
> DRM_ERROR("Failed to attach bridge to drm\n");
> goto err_encoder_cleanup;
> @@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
> }
>
> ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
> - &dsi->panel, &dsi->bridge);
> + &dsi->panel, &dsi->next_bridge);
> if (ret)
> goto err_unregister_host;
>
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月1日 週五 下午11:23寫道：
>
> Convert mtk_dsi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Enric Balletbo i Serra
> Acked-by: Sam Ravnborg
> ---
>
> Changes in v4:
> - Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
> - Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)
>
> Changes in v3:
> - Add the bridge.type. (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 108 +++--
> 1 file changed, 70 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 37b8d7ffd835..38cbdcb15fff 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -180,6 +180,7 @@ struct mtk_dsi {
> struct device *dev;
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> + struct drm_bridge bridge;
> struct drm_connector conn;
> struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> @@ -205,9 +206,9 @@ struct mtk_dsi {
> const struct mtk_dsi_driver_data *driver_data;
> };
>
> -static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> +static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> {
> - return container_of(e, struct mtk_dsi, encoder);
> + return container_of(b, struct mtk_dsi, bridge);
> }
>
> static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> @@ -796,32 +797,43 @@ static const struct drm_encoder_funcs
> mtk_dsi_encoder_funcs = {
> .destroy = mtk_dsi_encoder_destroy,
> };
>
> -static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> +static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> +
> +static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> {
> - return true;
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> + return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> +}
> +
> +static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> +{
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> + mtk_dsi_destroy_conn_enc(dsi);
> }
>
> -static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted)
> +static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> drm_display_mode_to_videomode(adjusted, &dsi->vm);
> }
>
> -static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_disable(dsi);
> }
>
> -static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_enable(dsi);
> }
> @@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct
> drm_connector *connector)
> return drm_panel_get_modes(dsi->panel, connector);
> }
>
> -static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
> - .mode_fixup = mtk_dsi_encoder_mode_fixup,
> - .mode_set = mtk_dsi_encoder_mode_set,
> - .disable = mtk_dsi_encoder_disable,
> - .enable = mtk_dsi_encoder_enable,
> +static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
> + .attach = mtk_dsi_bridge_attach,
> + .detach = mtk_dsi_bridge_detach,
> + .disable = mtk_dsi_bridge_disable,
> + .enable = mtk_dsi_bridge_enable,
> + .mode_set = mtk_dsi_bridge_mode_set,
> };
>
> static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
> @@ -888,20 +901,6 @@ static int mtk_dsi_create_conn_enc(struct drm_device
> *drm, struct mtk_dsi *dsi)
> {
> int ret;
>
> - ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
> - DRM_MODE_ENCODER_DSI, NULL);
> - if (ret) {
> - DRM_ERROR("Failed to encoder init to drm\n");
> - return r
Re: [PATCH hmm v2 5/5] mm/hmm: remove the customizable pfn format from hmm_range_fault
On 5/1/20 11:20 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as hmm_range_fault() provides CPU addresses which must be DMA mapped.
Perhaps there is some special HW that does not need DMA mapping, but we
don't have any examples of this, and the theoretical performance win of
avoiding an extra scan over the pfns array doesn't seem worth the
complexity. Plus pfns needs to be scanned anyhow to sort out any
DEVICE_PRIVATE pages.
This version replaces the uint64_t with an usigned long containing a pfn
and fixed flags. On input flags is filled with the HMM_PFN_REQ_* values,
on successful output it is filled with HMM_PFN_* values, describing the
state of the pages.
amdgpu is simple to convert, it doesn't use snapshot and doesn't use
per-page flags.
nouveau uses only 16 hmm_pte entries at most (ie fits in a few cache
lines), and it sweeps over its pfns array a couple of times anyhow. It
also has a nasty call chain before it reaches the dma map and hardware
suggesting performance isn't important:
nouveau_svm_fault():
args.i.m.method = NVIF_VMM_V0_PFNMAP
nouveau_range_fault()
nvif_object_ioctl()
client->driver->ioctl()
struct nvif_driver nvif_driver_nvkm:
.ioctl = nvkm_client_ioctl
nvkm_ioctl()
nvkm_ioctl_path()
nvkm_ioctl_v0[type].func(..)
nvkm_ioctl_mthd()
nvkm_object_mthd()
struct nvkm_object_func nvkm_uvmm:
.mthd = nvkm_uvmm_mthd
nvkm_uvmm_mthd()
nvkm_uvmm_mthd_pfnmap()
nvkm_vmm_pfn_map()
nvkm_vmm_ptes_get_map()
func == gp100_vmm_pgt_pfn
struct nvkm_vmm_desc_func gp100_vmm_desc_spt:
.pfn = gp100_vmm_pgt_pfn
nvkm_vmm_iter()
REF_PTES == func == gp100_vmm_pgt_pfn()
dma_map_page()
Acked-by: Felix Kuehling
Tested-by: Ralph Campbell
Signed-off-by: Jason Gunthorpe
Signed-off-by: Christoph Hellwig
---
Documentation/vm/hmm.rst| 26 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 35 ++
drivers/gpu/drm/nouveau/nouveau_dmem.c | 27 +---
drivers/gpu/drm/nouveau/nouveau_dmem.h | 3 +-
drivers/gpu/drm/nouveau/nouveau_svm.c | 87 -
include/linux/hmm.h | 99 ++-
mm/hmm.c| 160 +++-
7 files changed, 192 insertions(+), 245 deletions(-)
...snip...
+static void nouveau_hmm_convert_pfn(struct nouveau_drm *drm,
+ struct hmm_range *range, u64 *ioctl_addr)
+{
+ unsigned long i, npages;
+
+ /*
+* The ioctl_addr prepared here is passed through nvif_object_ioctl()
+* to an eventual DMA map in something like gp100_vmm_pgt_pfn()
+*
+* This is all just encoding the internal hmm reprensetation into a
s/reprensetation/representation/
Looks good and still tests OK with nouveau.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/29] mm: remove the pgprot argument to __vmalloc
On Thu, 30 Apr 2020 22:38:10 -0400 John Dorminy wrote: > the change > description refers to PROT_KERNEL, which is a symbol which does not > appear to exist; perhaps PAGE_KERNEL was meant? Yes, thanks, fixed. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/mm: insert_hole_addr() can be static
Signed-off-by: kbuild test robot
---
drm_mm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index effc6e5cac459..89df90a6052d1 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -245,7 +245,7 @@ RB_DECLARE_CALLBACKS_MAX(static, augment_callbacks,
struct drm_mm_node, rb_hole_addr,
u64, subtree_max_hole, HOLE_SIZE)
-void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node)
+static void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node)
{
struct rb_node **link = &root->rb_node, *rb_parent = NULL;
u64 start = HOLE_ADDR(node), subtree_max_hole = node->subtree_max_hole;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] drm/mm: optimize rb_hole_addr rbtree search
Hi Nirmoy, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.7-rc3 next-20200501] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Nirmoy-Das/drm-mm-optimize-rb_hole_addr-rbtree-search/20200501-165835 base: git://anongit.freedesktop.org/drm-intel for-linux-next reproduce: # apt-get install sparse # sparse version: v0.6.1-191-gc51a0382-dirty make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/drm_mm.c:248:6: sparse: sparse: symbol 'insert_hole_addr' >> was not declared. Should it be static? drivers/gpu/drm/drm_mm.c:401:24: sparse: sparse: Using plain integer as NULL pointer drivers/gpu/drm/drm_mm.c:441:24: sparse: sparse: Using plain integer as NULL pointer Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
On Thu, 30 Apr 2020 17:34:11 +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
>
> You can add support to your board with binding.
>
> Example:
> anx7625_bridge: encoder@58 {
> compatible = "analogix,anx7625";
> reg = <0x58>;
> status = "okay";
> enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> mipi2dp_bridge_in: port@0 {
> reg = <0>;
> anx7625_in: endpoint {
> remote-endpoint = <&mipi_dsi>;
> };
> };
>
> mipi2dp_bridge_out: port@1 {
> reg = <1>;
> anx7625_out: endpoint {
> remote-endpoint = <&panel_in>;
> };
> };
> };
> };
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/analogix,anx7625.yaml | 97
> ++
> 1 file changed, 97 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dts:21.13-26:
Warning (reg_format): /example-0/encoder@58:reg: property has invalid length
(4 bytes) (#address-cells == 1, #size-cells == 1)
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.example.dt.yaml:
Warning (spi_bus_reg): Failed prerequisite 'reg_format'
See https://patchwork.ozlabs.org/patch/1280084
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
--upgrade
Please check and re-submit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Add support for TM5P5 NT35596 video mode panel
Hi Konrad. On Fri, May 01, 2020 at 10:48:21PM +0200, Konrad Dybcio wrote: > I am aware of the fact that this is probably not the correct > naming of this panel, yet I am unable to retrieve any additional > information about it, as it is used in a smartphone to which no > schematics are released. > > The driver has been generated with the help of > linux-mdss-dsi-panel-driver-generator [1] and works perfectly > on a Asus Zenfone 2 Laser Z00T smartphone, including brighness > control and switching on/off. > > [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator Panle driver looks good. Will take a closer look tomorrow. Any chance you can work on the TODO in the driver so we can have that resolved before we apply it? Also for a v2 it would be perfect if you could work on top of drm-misc-next. There is at least one small fix needed to build that I spotted. But wait until I get back on the driver patch before submitting a v2. Sam > > Konrad Dybcio (2): > drivers: drm: panel: Add TM5P5 NT35596 panel driver > dt-bindings: display: Document TM5P5 NT35596 panel compatible > > .../bindings/display/panel/tm5p5,nt35596.txt | 7 + > drivers/gpu/drm/panel/Kconfig | 9 + > drivers/gpu/drm/panel/Makefile| 1 + > drivers/gpu/drm/panel/panel-tm5p5-nt35596.c | 366 ++ > 4 files changed, 383 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt > create mode 100644 drivers/gpu/drm/panel/panel-tm5p5-nt35596.c > > -- > 2.26.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: display: Document TM5P5 NT35596 panel compatible
Hi Konrad. Thanks for the new panel binding. But you need to redo this as panel bindings today must be in DT Schema format (.yaml). Please see other bindings in the same dir for examples. Sam On Fri, May 01, 2020 at 10:48:23PM +0200, Konrad Dybcio wrote: > Signed-off-by: Konrad Dybcio > --- > .../devicetree/bindings/display/panel/tm5p5,nt35596.txt| 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt > b/Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt > new file mode 100644 > index 0..6be56983482bf > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/tm5p5,nt35596.txt > @@ -0,0 +1,7 @@ > +TM5P5 NT35596 5.5" 1080×1920 LCD Panel > + > +Required properties: > + - compatible: "tm5p5,nt35596" > + - reset-gpios: GPIO spec for reset pin > + - vdd-supply: VDD regulator > + - vddio-supply: VDDIO regulator > -- > 2.26.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 07/10] dt-bindings: display: add i.MX6 MIPI DSI host controller doc
On Mon, Apr 27, 2020 at 11:19:49AM +0300, Adrian Ratiu wrote:
> This provides an example DT binding for the MIPI DSI host controller
> present on the i.MX6 SoC based on Synopsis DesignWare v1.01 IP.
>
> Cc: Rob Herring
> Cc: Neil Armstrong
> Cc: Fabio Estevam
> Cc: Laurent Pinchart
> Cc: devicet...@vger.kernel.org
> Tested-by: Adrian Pop
> Tested-by: Arnaud Ferraris
> Signed-off-by: Sjoerd Simons
> Signed-off-by: Martyn Welch
> Signed-off-by: Adrian Ratiu
> ---
> Changes since v7:
> - Clarified port@0,1 descriptions, marked them as required and
> added missing port@0 in example (Laurent)
>
> Changes since v6:
> - Added ref to the newly created snps,dw-mipi-dsi.yaml (Laurent)
> - Moved *-cells properties outside patternProperties (Laurent)
> - Removed the panel port documentation (Laurent)
> - Wrapped lines at 80 chars, typo fixes, sort includes (Laurent)
>
> Changes since v5:
> - Fixed missing reg warning (Fabio)
> - Updated dt-schema and fixed warnings (Rob)
>
> Changes since v4:
> - Fixed yaml binding to pass `make dt_binding_check dtbs_check`
> and addressed received binding feedback (Rob)
>
> Changes since v3:
> - Added commit message (Neil)
> - Converted to yaml format (Neil)
> - Minor dt node + driver fixes (Rob)
> - Added small panel example to the host controller binding
>
> Changes since v2:
> - Fixed commit tags (Emil)
> ---
> .../display/imx/fsl,mipi-dsi-imx6.yaml| 145 ++
> 1 file changed, 145 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> new file mode 100644
> index 0..c2c3489e63fa3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,mipi-dsi-imx6.yaml
> @@ -0,0 +1,145 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,mipi-dsi-imx6.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX6 DW MIPI DSI Host Controller
> +
> +maintainers:
> + - Adrian Ratiu
> +
> +description: |
> + The i.MX6 DSI host controller is a Synopsys DesignWare MIPI DSI v1.01
> + IP block with a companion PHY IP.
> +
> + These DT bindings follow the Synopsys DW MIPI DSI bindings defined in
> + Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt with
> + the following device-specific properties.
> +
> +allOf:
> + - $ref: ../bridge/snps,dw-mipi-dsi.yaml#
> +
> +properties:
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + compatible:
> +items:
> + - const: fsl,imx6q-mipi-dsi
> + - const: snps,dw-mipi-dsi
This schema is going to be applied on any node with 'snps,dw-mipi-dsi'.
You'll need a custom 'select' with only 'fsl,imx6q-mipi-dsi'. There's a
few examples in the tree.
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: Module Clock
> + - description: DSI bus clock
> +
> + clock-names:
> +items:
> + - const: ref
> + - const: pclk
> +
> + fsl,gpr:
> +description:
> + Phandle to the iomuxc-gpr region containing the multiplexer ctrl
> register.
> +$ref: /schemas/types.yaml#/definitions/phandle
> +
> + ports:
> +type: object
> +description: |
> + A node containing DSI input & output port nodes with endpoint
> + definitions as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> +properties:
> + port@0:
> +type: object
> +description:
> + DSI input port connected to a parallel RGB LTDC output port.
> +
> + port@1:
> +type: object
> +description:
> + DSI serial RGB output port connected to a panel or bridge input
> port.
> +
> +required:
> + - port@0
> + - port@1
> +
> +additionalProperties: false
When including other schemas, you need 'unevalatedProperties: false'
instead. Then you can drop anything here that doesn't have more
constraints like the next property:
> +
> +patternProperties:
> + "^panel@[0-3]$":
> +type: object
> +
> +required:
> + - "#address-cells"
> + - "#size-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - ports
> +
> +examples:
> + - |+
> +#include
> +#include
> +#include
> +
> +dsi: dsi@21e {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
> +reg = <0x021e 0x4000>;
> +interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
> +fsl,gpr = <&gpr>;
> +clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
> + <&clk
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #32 from j.cordoba (j.cord...@gmx.net) --- I agree. Fixed for me too -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/msm: Check for powered down HW in the devfreq callbacks
Writing to the devfreq sysfs nodes while the GPU is powered down can
result in a system crash (on a5xx) or a nasty GMU error (on a6xx):
$ /sys/class/devfreq/500.gpu# echo 5 > min_freq
[ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob]
*ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0
Despite the fact that we carefully try to suspend the devfreq device when
the hardware is powered down there are lots of holes in the governors that
don't check for the suspend state and blindly call into the devfreq
callbacks that end up triggering hardware reads in the GPU driver.
Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq()
callbacks to skip the hardware access if it isn't active.
v3: Only check pm_runtime_get_if_in_use() for == 0 per Eric Anholt
v2: Use pm_runtime_get_if_in_use() per Eric Anholt
Cc: sta...@vger.kernel.org
Reviewed-by: Eric Anholt
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 724024a2243a..662d02289533 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1404,6 +1404,10 @@ static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
u64 busy_cycles, busy_time;
+ /* Only read the gpu busy if the hardware is already active */
+ if (pm_runtime_get_if_in_use(&gpu->pdev->dev) == 0)
+ return 0;
+
busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
@@ -1412,6 +1416,8 @@ static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
gpu->devfreq.busy_cycles = busy_cycles;
+ pm_runtime_put(&gpu->pdev->dev);
+
if (WARN_ON(busy_time > ~0LU))
return ~0LU;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index c4e71abbdd53..34607a98cc7c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -108,6 +108,13 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
struct msm_gpu *gpu = &adreno_gpu->base;
int ret;
+ /*
+* This can get called from devfreq while the hardware is idle. Don't
+* bring up the power if it isn't already active
+*/
+ if (pm_runtime_get_if_in_use(gmu->dev) == 0)
+ return;
+
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
@@ -134,6 +141,7 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
* for now leave it at max so that the performance is nominal.
*/
icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+ pm_runtime_put(gmu->dev);
}
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 68af24150de5..2c09d2c21773 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -810,6 +810,11 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
u64 busy_cycles, busy_time;
+
+ /* Only read the gpu busy if the hardware is already active */
+ if (pm_runtime_get_if_in_use(a6xx_gpu->gmu.dev) == 0)
+ return 0;
+
busy_cycles = gmu_read64(&a6xx_gpu->gmu,
REG_A6XX_GMU_CX_GMU_POWER_COUNTER_XOCLK_0_L,
REG_A6XX_GMU_CX_GMU_POWER_COUNTER_XOCLK_0_H);
@@ -819,6 +824,8 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
gpu->devfreq.busy_cycles = busy_cycles;
+ pm_runtime_put(a6xx_gpu->gmu.dev);
+
if (WARN_ON(busy_time > ~0LU))
return ~0LU;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/msm: Check for powered down HW in the devfreq callbacks
On Fri, May 1, 2020 at 12:03 PM Jordan Crouse wrote:
>
> Writing to the devfreq sysfs nodes while the GPU is powered down can
> result in a system crash (on a5xx) or a nasty GMU error (on a6xx):
>
> $ /sys/class/devfreq/500.gpu# echo 5 > min_freq
> [ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob]
> *ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0
>
> Despite the fact that we carefully try to suspend the devfreq device when
> the hardware is powered down there are lots of holes in the governors that
> don't check for the suspend state and blindly call into the devfreq
> callbacks that end up triggering hardware reads in the GPU driver.
>
> Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq()
> callbacks to skip the hardware access if it isn't active.
>
> v2: Use pm_runtime_get_if_in_use() per Eric Anholt
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 ++
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 +++
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 724024a2243a..4d7f269edfcc 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1404,6 +1404,10 @@ static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
> {
> u64 busy_cycles, busy_time;
>
> + /* Only read the gpu busy if the hardware is already active */
> + if (pm_runtime_get_if_in_use(&gpu->pdev->dev) <= 0)
> + return 0;
> +
RPM's APIs are a bit of a trap and will return a negative errno for
the get functions if runtime PM is disabled in kconfig, even though
usually that would mean that the power domain is not ever disabled by
RPM. I think in these checks you want "if (pm_runtime_get_if_in_use()
== 0)", and that seems to be a common pattern in other drivers. With
that,
Reviewed-by: Eric Anholt
(and tested, too)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdkfd: Remove logically dead code in kfd_procfs_show
container_of is never null, so the null check on pdd is unnecessary.
If the null check is removed, function kfd_procfs_show()
will always return before reaching "return 0", hence
such return is logically dead. So, remove it, as well.
Addresses-Coverity-ID: 1492793 ("Logically dead code")
Fixes: d4566dee849e ("drm/amdkfd: Track GPU memory utilization per process")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 598296034b43..63dcd30b2cdc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -87,14 +87,11 @@ static ssize_t kfd_procfs_show(struct kobject *kobj, struct
attribute *attr,
} else if (strncmp(attr->name, "vram_", 5) == 0) {
struct kfd_process_device *pdd = container_of(attr, struct
kfd_process_device,
attr_vram);
- if (pdd)
- return snprintf(buffer, PAGE_SIZE, "%llu\n",
READ_ONCE(pdd->vram_usage));
+ return snprintf(buffer, PAGE_SIZE, "%llu\n",
READ_ONCE(pdd->vram_usage));
} else {
pr_err("Invalid attribute");
return -EINVAL;
}
-
- return 0;
}
static void kfd_procfs_kobj_release(struct kobject *kobj)
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm: Check for powered down HW in the devfreq callbacks
Writing to the devfreq sysfs nodes while the GPU is powered down can
result in a system crash (on a5xx) or a nasty GMU error (on a6xx):
$ /sys/class/devfreq/500.gpu# echo 5 > min_freq
[ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob]
*ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0
Despite the fact that we carefully try to suspend the devfreq device when
the hardware is powered down there are lots of holes in the governors that
don't check for the suspend state and blindly call into the devfreq
callbacks that end up triggering hardware reads in the GPU driver.
Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq()
callbacks to skip the hardware access if it isn't active.
v2: Use pm_runtime_get_if_in_use() per Eric Anholt
Cc: sta...@vger.kernel.org
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 +++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 724024a2243a..4d7f269edfcc 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1404,6 +1404,10 @@ static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
u64 busy_cycles, busy_time;
+ /* Only read the gpu busy if the hardware is already active */
+ if (pm_runtime_get_if_in_use(&gpu->pdev->dev) <= 0)
+ return 0;
+
busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
@@ -1412,6 +1416,8 @@ static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
gpu->devfreq.busy_cycles = busy_cycles;
+ pm_runtime_put(&gpu->pdev->dev);
+
if (WARN_ON(busy_time > ~0LU))
return ~0LU;
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index c4e71abbdd53..8ace989b11db 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -108,6 +108,13 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
struct msm_gpu *gpu = &adreno_gpu->base;
int ret;
+ /*
+* This can get called from devfreq while the hardware is idle. Don't
+* bring up the power if it isn't already active
+*/
+ if (pm_runtime_get_if_in_use(gmu->dev) <= 0)
+ return;
+
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
@@ -134,6 +141,7 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
* for now leave it at max so that the performance is nominal.
*/
icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+ pm_runtime_put(gmu->dev);
}
void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 68af24150de5..bf43eb2fb078 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -810,6 +810,11 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
u64 busy_cycles, busy_time;
+
+ /* Only read the gpu busy if the hardware is already active */
+ if (pm_runtime_get_if_in_use(a6xx_gpu->gmu.dev) <= 0)
+ return 0;
+
busy_cycles = gmu_read64(&a6xx_gpu->gmu,
REG_A6XX_GMU_CX_GMU_POWER_COUNTER_XOCLK_0_L,
REG_A6XX_GMU_CX_GMU_POWER_COUNTER_XOCLK_0_H);
@@ -819,6 +824,8 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
gpu->devfreq.busy_cycles = busy_cycles;
+ pm_runtime_put(a6xx_gpu->gmu.dev);
+
if (WARN_ON(busy_time > ~0LU))
return ~0LU;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
On Fri, May 1, 2020 at 4:08 AM Robin Murphy wrote:
>
> On 2020-05-01 11:21 am, Brian Starkey wrote:
> > Hi John,
> >
> > On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wrote:
> >> This patch reworks the cma_heap initialization so that
> >> we expose both the default CMA region and any CMA regions
> >> tagged with "linux,cma-heap" in the device-tree.
> >>
> >> Cc: Rob Herring
> >> Cc: Sumit Semwal
> >> Cc: "Andrew F. Davis"
> >> Cc: Benjamin Gaignard
> >> Cc: Liam Mark
> >> Cc: Pratik Patel
> >> Cc: Laura Abbott
> >> Cc: Brian Starkey
> >> Cc: Chenbo Feng
> >> Cc: Alistair Strachan
> >> Cc: Sandeep Patil
> >> Cc: Hridya Valsaraju
> >> Cc: Christoph Hellwig
> >> Cc: Marek Szyprowski
> >> Cc: Robin Murphy
> >> Cc: Andrew Morton
> >> Cc: devicet...@vger.kernel.org
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: linux...@kvack.org
> >> Signed-off-by: John Stultz
> >> ---
> >> drivers/dma-buf/heaps/cma_heap.c | 18 +-
> >> 1 file changed, 9 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> >> b/drivers/dma-buf/heaps/cma_heap.c
> >> index 626cf7fd033a..dd154e2db101 100644
> >> --- a/drivers/dma-buf/heaps/cma_heap.c
> >> +++ b/drivers/dma-buf/heaps/cma_heap.c
> >> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
> >> {
> >> struct cma_heap *cma_heap;
> >> struct dma_heap_export_info exp_info;
> >> +struct cma *default_cma = dev_get_cma_area(NULL);
> >> +
> >> +/* We only add the default heap and explicitly tagged heaps */
> >> +if (cma != default_cma && !cma_dma_heap_enabled(cma))
> >> +return 0;
> >
> > Thinking about the pl111 thread[1], I'm wondering if we should also
> > let drivers call this directly to expose their CMA pools, even if they
> > aren't tagged for dma-heaps in DT. But perhaps that's too close to
> > policy.
>
> That sounds much like what my first thoughts were - apologies if I'm
> wildly off-base here, but as far as I understand:
>
> - Device drivers know whether they have their own "memory-region" or not.
> - Device drivers already have to do *something* to participate in dma-buf.
> - Device drivers know best how they make use of both the above.
> - Therefore couldn't it be left to drivers to choose whether to register
> their CMA regions as heaps, without having to mess with DT at all?
I guess I'm not opposed to this. But I guess I'd like to see some more
details? You're thinking the pl111 driver would add the
"memory-region" node itself?
Assuming that's the case, my only worry is what if that memory-region
node isn't a CMA area, but instead something like a carveout? Does the
driver need to parse enough of the dt to figure out where to register
the region as a heap?
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Check for powered down HW in the devfreq callbacks
On Fri, May 1, 2020 at 11:26 AM Jordan Crouse wrote: > > Writing to the devfreq sysfs nodes while the GPU is powered down can > result in a system crash (on a5xx) or a nasty GMU error (on a6xx): > > $ /sys/class/devfreq/500.gpu# echo 5 > min_freq > [ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob] > *ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0 > > Despite the fact that we carefully try to suspend the devfreq device when > the hardware is powered down there are lots of holes in the governors that > don't check for the suspend state and blindly call into the devfreq > callbacks that end up triggering hardware reads in the GPU driver. > > Check the power state in the gpu_busy() and gpu_set_freq() callbacks for > a5xx and a6xx to make sure that the hardware is active before trying to > access it. Chatted on IRC -- while this avoids the instaboot on db820c when setting /sys/class/devfreq/devfreq1/min_freq, I think we should be using pm_runtime_get_if_in_use() to avoid the races while still avoiding bringing up the GPU. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtio: create context before RESOURCE_CREATE_2D in 3D mode
If 3D is enabled, but userspace requests a dumb buffer, we will
call CTX_ATTACH_RESOURCE before actually creating the context.
Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context
after the first 3D ioctl")
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_gem.c | 3 +++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +--
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 49bebdee6d91..9ff9f4ac0522 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -221,6 +221,7 @@ struct virtio_gpu_fpriv {
/* virtgpu_ioctl.c */
#define DRM_VIRTIO_NUM_IOCTLS 10
extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
+void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file);
/* virtgpu_kms.c */
int virtio_gpu_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 1025658be4df..d6cb350ae52a 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -39,6 +39,9 @@ static int virtio_gpu_gem_create(struct drm_file *file,
int ret;
u32 handle;
+ if (vgdev->has_virgl_3d)
+ virtio_gpu_create_context(dev, file);
+
ret = virtio_gpu_object_create(vgdev, params, &obj, NULL);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 867c5e239d55..6c7619c13277 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -33,8 +33,7 @@
#include "virtgpu_drv.h"
-static void virtio_gpu_create_context(struct drm_device *dev,
- struct drm_file *file)
+void virtio_gpu_create_context(struct drm_device *dev, struct drm_file *file)
{
struct virtio_gpu_device *vgdev = dev->dev_private;
struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
--
2.26.2.526.g744177e7f7-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/4] mm: cma: Add dma_heap flag to cma structure
On Fri, May 1, 2020 at 3:48 AM Brian Starkey wrote:
> On Fri, May 01, 2020 at 07:39:47AM +, John Stultz wrote:
> > +bool cma_dma_heap_enabled(struct cma *cma)
> > +{
> > + return !!cma->dma_heap;
>
> Stylistic thing, but I don't think the !! is really necessary. It's
> already a bool anyway.
Yea, I was using a bit field earlier and then moved to a bool for
simplicity and left this. I saw it as soon as I sent the patch, so
it's already fixed up.
> > @@ -157,6 +167,7 @@ static int __init cma_init_reserved_areas(void)
> > }
> > core_initcall(cma_init_reserved_areas);
> >
> > +
>
> nit: spurious newline
Yep. Same. The things you only see once the mail is sent. :)
Thanks so much for the review though!
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux, cma-heap tag for reserved memory
On Fri, May 1, 2020 at 3:42 AM Brian Starkey wrote: > > Hi, > > On Fri, May 01, 2020 at 07:39:46AM +, John Stultz wrote: > > This patch adds a linux,cma-heap property for CMA reserved memory > > regions, which will be used to allow the region to be exposed via > > the DMA-BUF Heaps interface > > > > Cc: Rob Herring > > Cc: Sumit Semwal > > Cc: "Andrew F. Davis" > > Cc: Benjamin Gaignard > > Cc: Liam Mark > > Cc: Pratik Patel > > Cc: Laura Abbott > > Cc: Brian Starkey > > Cc: Chenbo Feng > > Cc: Alistair Strachan > > Cc: Sandeep Patil > > Cc: Hridya Valsaraju > > Cc: Christoph Hellwig > > Cc: Marek Szyprowski > > Cc: Robin Murphy > > Cc: Andrew Morton > > Cc: devicet...@vger.kernel.org > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux...@kvack.org > > Signed-off-by: John Stultz > > --- > > .../devicetree/bindings/reserved-memory/reserved-memory.txt| 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > index bac4afa3b197..e97b6a4c3bc0 100644 > > --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > @@ -68,6 +68,9 @@ Linux implementation note: > > - If a "linux,cma-default" property is present, then Linux will use the > >region for the default pool of the contiguous memory allocator. > > > > +- If a "linux,cma-heap" property is present, then Linux will expose the > > + the CMA region via the DMA-BUF Heaps interface. > > + > > Would it be useful or even possible to give some indication of what > the heap will end up being called? I'm afraid I don't remember what if > any conclusions came out of previous discussions on UAPI for heap > enumeration. So the name we expose is the CMA name itself. So with dt it will be the name of the reserved memory node that the flag property is added to. > I suppose CMA names haven't been relevant to userspace before, but > they perhaps would be with this change. > > Alternatively, leaving it effectively undefined doesn't tie us down, > and something like links in sysfs can be added as a richer API in the > future. Hrm. Mind expanding on what you're thinking here? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.7-rc4
The pull request you sent on Fri, 1 May 2020 12:59:10 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-01 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/477bfeb9a3d712b6e1aeb4e37607faebf4b7f6d4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Check for powered down HW in the devfreq callbacks
Writing to the devfreq sysfs nodes while the GPU is powered down can
result in a system crash (on a5xx) or a nasty GMU error (on a6xx):
$ /sys/class/devfreq/500.gpu# echo 5 > min_freq
[ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob]
*ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0
Despite the fact that we carefully try to suspend the devfreq device when
the hardware is powered down there are lots of holes in the governors that
don't check for the suspend state and blindly call into the devfreq
callbacks that end up triggering hardware reads in the GPU driver.
Check the power state in the gpu_busy() and gpu_set_freq() callbacks for
a5xx and a6xx to make sure that the hardware is active before trying to
access it.
Cc: sta...@vger.kernel.org
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 724024a2243a..9d8c7fe6377e 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1404,6 +1404,10 @@ static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
{
u64 busy_cycles, busy_time;
+ /* devfreq can get here while we are idle so do a quick check first */
+ if (!pm_runtime_active(&gpu->pdev->dev))
+ return ~0LU;
+
busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index c4e71abbdd53..84618f2ff073 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -108,6 +108,10 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
index)
struct msm_gpu *gpu = &adreno_gpu->base;
int ret;
+ /* This can be called via devfreq even when the power is off */
+ if (!pm_runtime_active(gmu->dev))
+ return;
+
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 68af24150de5..443efc952f13 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -810,6 +810,10 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
u64 busy_cycles, busy_time;
+ /* devfreq can get here while we are idle so do a quick check first */
+ if (!pm_runtime_active(a6xx_gpu->gmu.dev))
+ return ~0LU;
+
busy_cycles = gmu_read64(&a6xx_gpu->gmu,
REG_A6XX_GMU_CX_GMU_POWER_COUNTER_XOCLK_0_L,
REG_A6XX_GMU_CX_GMU_POWER_COUNTER_XOCLK_0_H);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Fix undefined "rd_full" link error
On Thu, Apr 30, 2020 at 12:25 PM Bjorn Andersson
wrote:
>
> rd_full should be defined outside the CONFIG_DEBUG_FS region, in order
> to be able to link the msm driver even when CONFIG_DEBUG_FS is disabled.
>
> Fixes: e515af8d4a6f ("drm/msm: devcoredump should dump MSM_SUBMIT_BO_DUMP
> buffers")
> Reported-by: Stephen Rothwell
> Signed-off-by: Bjorn Andersson
thanks,
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_rd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
> index 732f65df5c4f..fea30e7aa9e8 100644
> --- a/drivers/gpu/drm/msm/msm_rd.c
> +++ b/drivers/gpu/drm/msm/msm_rd.c
> @@ -29,8 +29,6 @@
> * or shader programs (if not emitted inline in cmdstream).
> */
>
> -#ifdef CONFIG_DEBUG_FS
> -
> #include
> #include
> #include
> @@ -47,6 +45,8 @@ bool rd_full = false;
> MODULE_PARM_DESC(rd_full, "If true, $debugfs/.../rd will snapshot all buffer
> contents");
> module_param_named(rd_full, rd_full, bool, 0600);
>
> +#ifdef CONFIG_DEBUG_FS
> +
> enum rd_sect_type {
> RD_NONE,
> RD_TEST, /* ascii text */
> --
> 2.24.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 00/10] Remove duplicated kmap code
On Fri, May 01, 2020 at 01:54:56AM -0700, Christoph Hellwig wrote: > In addition to the work already it the series, it seems like > LAST_PKMAP_MASK, PKMAP_ADDR and PKMAP_NR can also be consolidated > to common code. Agreed, I mentioned in the cover letter there are similarities... > > Also kmap_atomic_high_prot / kmap_atomic_pfn could move into common > code, maybe keyed off a symbol selected by the actual users that > need it. It also seems like it doesn't actually ever need to be > exported. ... but these are not as readily obvious, at least to me. I do see a pattern but the differences seemed subtle enough that it would take a while to ensure correctness. So I'd like to see this series go in and build on it. > > This in turn would lead to being able to allow io_mapping_map_atomic_wc > on all architectures, which might make nouveau and qxl happy, but maybe > that can be left for another series. I agree, that this should be follow on patches. I still need to fix the bisect-ability and I don't want to bog down 0-day with a longer series. Thanks for the review! Ira ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Replace drm_modeset_lock/unlock_all with DRM_MODESET_LOCK_ALL_* helpers
On 30.04.2020 20:30, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
>>
>> On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula
>> wrote:
>>>
>>> On Tue, 28 Apr 2020, Michal Orzel wrote:
As suggested by the TODO list for the kernel DRM subsystem, replace
the deprecated functions that take/drop modeset locks with new helpers.
Signed-off-by: Michal Orzel
---
drivers/gpu/drm/drm_mode_object.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index 35c2719..901b078 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -402,12 +402,13 @@ int drm_mode_obj_get_properties_ioctl(struct
drm_device *dev, void *data,
{
struct drm_mode_obj_get_properties *arg = data;
struct drm_mode_object *obj;
+ struct drm_modeset_acquire_ctx ctx;
int ret = 0;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
>>>
>>> I cry a little every time I look at the DRM_MODESET_LOCK_ALL_BEGIN and
>>> DRM_MODESET_LOCK_ALL_END macros. :(
>>>
>>> Currently only six users... but there are ~60 calls to
>>> drm_modeset_lock_all{,_ctx} that I presume are to be replaced. I wonder
>>> if this will come back and haunt us.
>>>
>>
>> What's the alternative? Seems like the options without the macros is
>> to use incorrect scope or have a bunch of retry/backoff cargo-cult
>> everywhere (and hope the copy source is done correctly).
>
> Yeah Sean & me had a bunch of bikesheds and this is the least worst
> option we could come up with. You can't make it a function because of
> the control flow. You don't want to open code this because it's tricky
> to get right, if all you want is to just grab all locks. But it is
> magic hidden behind a macro, which occasionally ends up hurting.
> -Daniel
So what are we doing with this problem? Should we replace at once approx. 60
calls?
Michal
>
>> Sean
>>
>>> BR,
>>> Jani.
>>>
>>>
obj = drm_mode_object_find(dev, file_priv, arg->obj_id,
arg->obj_type);
if (!obj) {
@@ -427,7 +428,7 @@ int drm_mode_obj_get_properties_ioctl(struct
drm_device *dev, void *data,
out_unref:
drm_mode_object_put(obj);
out:
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(ctx, ret);
return ret;
}
@@ -449,12 +450,13 @@ static int set_property_legacy(struct
drm_mode_object *obj,
{
struct drm_device *dev = prop->dev;
struct drm_mode_object *ref;
+ struct drm_modeset_acquire_ctx ctx;
int ret = -EINVAL;
if (!drm_property_change_valid_get(prop, prop_value, &ref))
return -EINVAL;
- drm_modeset_lock_all(dev);
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
switch (obj->type) {
case DRM_MODE_OBJECT_CONNECTOR:
ret = drm_connector_set_obj_prop(obj, prop, prop_value);
@@ -468,7 +470,7 @@ static int set_property_legacy(struct drm_mode_object
*obj,
break;
}
drm_property_change_valid_put(prop, ref);
- drm_modeset_unlock_all(dev);
+ DRM_MODESET_LOCK_ALL_END(ctx, ret);
return ret;
}
>>>
>>> --
>>> Jani Nikula, Intel Open Source Graphics Center
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/14] docs: move other kAPI documents to core-api
There are a number of random documents that seem to be
describing some aspects of the core-api. Move them to such
directory, adding them at the core-api/index.rst file.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/sysctl/vm.rst | 2 +-
Documentation/core-api/index.rst| 6 ++
Documentation/{mailbox.txt => core-api/mailbox.rst} | 0
Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst} | 0
.../{this_cpu_ops.txt => core-api/this_cpu_ops.rst} | 0
.../unaligned-memory-access.rst}| 0
Documentation/gpu/drm-mm.rst| 2 +-
arch/Kconfig| 2 +-
init/Kconfig| 2 +-
mm/Kconfig | 2 +-
mm/nommu.c | 2 +-
11 files changed, 12 insertions(+), 6 deletions(-)
rename Documentation/{mailbox.txt => core-api/mailbox.rst} (100%)
rename Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst} (100%)
rename Documentation/{this_cpu_ops.txt => core-api/this_cpu_ops.rst} (100%)
rename Documentation/{unaligned-memory-access.txt =>
core-api/unaligned-memory-access.rst} (100%)
diff --git a/Documentation/admin-guide/sysctl/vm.rst
b/Documentation/admin-guide/sysctl/vm.rst
index 0329a4d3fa9e..0bf2f2a84a9f 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -583,7 +583,7 @@ trimming of allocations is initiated.
The default value is 1.
-See Documentation/nommu-mmap.txt for more information.
+See Documentation/core-api/nommu-mmap.rst for more information.
numa_zonelist_order
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index eeac63ba17c3..fe03a639a91a 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -38,10 +38,14 @@ Library functionality that is used throughout the kernel.
circular-buffers
rbtree
generic-radix-tree
+ mailbox
packing
+ rbtree
+ this_cpu_ops
timekeeping
errseq
+
Concurrency primitives
==
@@ -82,11 +86,13 @@ more memory-management documentation in :doc:`/vm/index`.
:maxdepth: 1
memory-allocation
+ unaligned-memory-access
dma-api
dma-api-howto
dma-attributes
dma-isa-lpc
bus-virt-phys-mapping
+ nommu-mmap
mm-api
genalloc
pin_user_pages
diff --git a/Documentation/mailbox.txt b/Documentation/core-api/mailbox.rst
similarity index 100%
rename from Documentation/mailbox.txt
rename to Documentation/core-api/mailbox.rst
diff --git a/Documentation/nommu-mmap.txt
b/Documentation/core-api/nommu-mmap.rst
similarity index 100%
rename from Documentation/nommu-mmap.txt
rename to Documentation/core-api/nommu-mmap.rst
diff --git a/Documentation/this_cpu_ops.txt
b/Documentation/core-api/this_cpu_ops.rst
similarity index 100%
rename from Documentation/this_cpu_ops.txt
rename to Documentation/core-api/this_cpu_ops.rst
diff --git a/Documentation/unaligned-memory-access.txt
b/Documentation/core-api/unaligned-memory-access.rst
similarity index 100%
rename from Documentation/unaligned-memory-access.txt
rename to Documentation/core-api/unaligned-memory-access.rst
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 1839762044be..e0bbcbb6f512 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -314,7 +314,7 @@ To use drm_gem_cma_get_unmapped_area(), drivers must fill
the struct
a pointer on drm_gem_cma_get_unmapped_area().
More detailed information about get_unmapped_area can be found in
-Documentation/nommu-mmap.txt
+Documentation/core-api/nommu-mmap.rst
Memory Coherency
diff --git a/arch/Kconfig b/arch/Kconfig
index 786a85d4ad40..b0b4046c9d13 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -147,7 +147,7 @@ config HAVE_EFFICIENT_UNALIGNED_ACCESS
problems with received packets if doing so would not help
much.
- See Documentation/unaligned-memory-access.txt for more
+ See Documentation/core-api/unaligned-memory-access.rst for more
information on the topic of unaligned memory accesses.
config ARCH_USE_BUILTIN_BSWAP
diff --git a/init/Kconfig b/init/Kconfig
index 492bb7000aa4..61ccfd9243e3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1950,7 +1950,7 @@ config MMAP_ALLOW_UNINITIALIZED
userspace. Since that isn't generally a problem on no-MMU systems,
it is normally safe to say Y here.
- See Documentation/nommu-mmap.txt for more information.
+ See Documentation/core-api/nommu-mmap.rst for more information.
config SYSTEM_DATA_VERIFICATION
def_bool n
diff --git a/mm/Kconfig b/mm/Kconfig
index db626b8d4fdb..2a133c40a4b7 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -382,7 +382,7 @@ config NOMMU_
Re: sparc-related comment, to Re: [PATCH V1 07/10] arch/kmap: Ensure kmap_prot visibility
On Fri, May 01, 2020 at 01:44:46AM -0700, Christoph Hellwig wrote: > > --- a/arch/sparc/mm/highmem.c > > +++ b/arch/sparc/mm/highmem.c > > @@ -33,6 +33,7 @@ > > #include > > > > pgprot_t kmap_prot; > > +EXPORT_SYMBOL(kmap_prot); > > Btw, I don't see why sparc needs this as a variable, as there is just > a single assignment to it. Because sparc uses non-standard defines which I'm not familiar with. kmap_prot = __pgprot(SRMMU_ET_PTE | SRMMU_PRIV | SRMMU_CACHE); SRMMU_ET_PTE and friends are defined in arch/sparc/include/asm/pgtsrmmu.h Since I can't readily test sparc this was easier to put out than let 0-day crank on the entire series checking if including that header in the common header chain would be an issue. > > If sparc is sorted out we can always make it a define, and use a define > for kmap_prot that defaults to PAGE_KERNEL, avoiding a little > more duplication. Agreed. But it seems easier as a follow up (for me with 0-day). Perhaps someone from sparc can weigh in on the specifics of those defines and why they are different from the normal ones? Or even provide a follow on patch? Ira ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] arm64: dts: qcom: sc7180: Add A618 gpu dt blob
Hi, On Fri, May 1, 2020 at 3:30 AM Sharat Masetty wrote: > > This patch adds the required dt nodes and properties > to enabled A618 GPU. > > Signed-off-by: Sharat Masetty > --- > * Remove GCC_DDRSS_GPU_AXI_CLK clock reference from gpu smmu node. > > arch/arm64/boot/dts/qcom/sc7180.dtsi | 102 > +++ > 1 file changed, 102 insertions(+) This is the newer version of the patch: https://lore.kernel.org/r/1581320465-15854-2-git-send-email-smase...@codeaurora.org The change to remove the extra IOMMU clock matches our discussions and there's no longer anything blocking this from landing. Reviewed-by: Douglas Anderson Tested-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: arm-smmu: Add sc7180 compatible string
Hi, On Fri, May 1, 2020 at 3:30 AM Sharat Masetty wrote: > > This patch simply adds a new compatible string for SC7180 platform. > > Signed-off-by: Sharat Masetty > --- > Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Douglas Anderson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi, Enric:
Enric Balletbo i Serra 於 2020年4月17日 週五 下午11:06寫道：
>
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the last bridge in
> the chain creating the connector and handling all connector operations
> internally.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v3:
> - Move the bridge.type line to the patch that adds drm_bridge support.
> (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 157097c63b23..85f76b01ae4d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -183,6 +184,7 @@ struct mtk_dsi {
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> struct drm_bridge *next_bridge;
> + struct drm_connector *connector;
> struct phy *phy;
>
> void __iomem *regs;
> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> struct mtk_dsi *dsi)
> */
> dsi->encoder.possible_crtcs = 1;
>
> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> if (ret)
> goto err_cleanup_encoder;
>
> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> + if (IS_ERR(dsi->connector)) {
> + DRM_ERROR("Unable to create bridge connector\n");
> + ret = PTR_ERR(dsi->connector);
> + goto err_cleanup_encoder;
> + }
> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
> +
I'm not very clear about how brige-connector works, but why connector
does not attach to panel?
Regards,
Chun-Kuang.
> return 0;
>
> err_cleanup_encoder:
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
Hi, Enric:
Enric Balletbo i Serra 於 2020年4月17日 週五 下午11:06寫道：
>
> Replace the manual panel handling code by a drm_panel_bridge. This
> simplifies the driver and allows all components in the display pipeline
> to be treated as bridges, paving the way to generic connector handling.
>
Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Laurent Pinchart
> ---
>
> Changes in v3:
> - Use next_bridge field to store the panel bridge. (Laurent Pinchart)
> - Add the bridge.type field. (Laurent Pinchart)
> - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
> properly.
>
> Changes in v2:
> - Do not set connector_type for panel here. (Sam Ravnborg)
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 187 +++--
> 1 file changed, 14 insertions(+), 173 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index d68694ff00dc..157097c63b23 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -182,8 +182,6 @@ struct mtk_dsi {
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> - struct drm_connector conn;
> - struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> struct phy *phy;
>
> @@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct
> drm_bridge *b)
> return container_of(b, struct mtk_dsi, bridge);
> }
>
> -static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> -{
> - return container_of(c, struct mtk_dsi, conn);
> -}
> -
> static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
> {
> return container_of(h, struct mtk_dsi, host);
> @@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to prepare the panel\n");
> - goto err_disable_digital_clk;
> - }
> - }
> -
> return 0;
> -err_disable_digital_clk:
> - clk_disable_unprepare(dsi->digital_clk);
> err_disable_engine_clk:
> clk_disable_unprepare(dsi->engine_clk);
> err_phy_power_off:
> @@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> */
> mtk_dsi_stop(dsi);
>
> - if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> - if (dsi->panel) {
> - if (drm_panel_unprepare(dsi->panel)) {
> - DRM_ERROR("failed to unprepare the panel\n");
> - return;
> - }
> - }
> - }
> -
> + mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
> mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
> @@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>
> mtk_dsi_start(dsi);
>
> - if (dsi->panel) {
> - if (drm_panel_enable(dsi->panel)) {
> - DRM_ERROR("failed to enable the panel\n");
> - goto err_dsi_power_off;
> - }
> - }
> -
> dsi->enabled = true;
> -
> - return;
> -err_dsi_power_off:
> - mtk_dsi_stop(dsi);
> - mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> @@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> if (!dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_disable(dsi->panel)) {
> - DRM_ERROR("failed to disable the panel\n");
> - return;
> - }
> - }
> -
> mtk_dsi_poweroff(dsi);
>
> dsi->enabled = false;
> }
>
> -static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> -static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> -
> static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> - return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> -}
> -
> -static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> -{
> - struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> -
> - mtk_dsi_destroy_conn_enc(dsi);
> + /* Attach the panel or bridge to the dsi bridge */
> + return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> +&dsi->bridge, flags);
> }
>
> static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
> @@ -830,115 +779,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge
> *bridge)
> mtk_output_dsi_enable(d
Re: [PATCH v3 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
Enric Balletbo i Serra 於 2020年4月17日 週五 下午11:06寫道：
>
> Replace the manual panel handling code by a drm_panel_bridge. This
> simplifies the driver and allows all components in the display pipeline
> to be treated as bridges, paving the way to generic connector handling.
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Laurent Pinchart
> ---
>
> Changes in v3:
> - Use next_bridge field to store the panel bridge. (Laurent Pinchart)
> - Add the bridge.type field. (Laurent Pinchart)
> - This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
> properly.
>
> Changes in v2:
> - Do not set connector_type for panel here. (Sam Ravnborg)
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 187 +++--
> 1 file changed, 14 insertions(+), 173 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index d68694ff00dc..157097c63b23 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -182,8 +182,6 @@ struct mtk_dsi {
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> struct drm_bridge bridge;
> - struct drm_connector conn;
> - struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> struct phy *phy;
>
> @@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct
> drm_bridge *b)
> return container_of(b, struct mtk_dsi, bridge);
> }
>
> -static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> -{
> - return container_of(c, struct mtk_dsi, conn);
> -}
> -
> static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
> {
> return container_of(h, struct mtk_dsi, host);
> @@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to prepare the panel\n");
> - goto err_disable_digital_clk;
> - }
> - }
> -
> return 0;
> -err_disable_digital_clk:
> - clk_disable_unprepare(dsi->digital_clk);
> err_disable_engine_clk:
> clk_disable_unprepare(dsi->engine_clk);
> err_phy_power_off:
> @@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> */
> mtk_dsi_stop(dsi);
>
> - if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> - if (dsi->panel) {
> - if (drm_panel_unprepare(dsi->panel)) {
> - DRM_ERROR("failed to unprepare the panel\n");
> - return;
> - }
> - }
> - }
> -
> + mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
> mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
> @@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>
> mtk_dsi_start(dsi);
>
> - if (dsi->panel) {
> - if (drm_panel_enable(dsi->panel)) {
> - DRM_ERROR("failed to enable the panel\n");
> - goto err_dsi_power_off;
> - }
> - }
> -
> dsi->enabled = true;
> -
> - return;
> -err_dsi_power_off:
> - mtk_dsi_stop(dsi);
> - mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> @@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> if (!dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_disable(dsi->panel)) {
> - DRM_ERROR("failed to disable the panel\n");
> - return;
> - }
> - }
> -
> mtk_dsi_poweroff(dsi);
>
> dsi->enabled = false;
> }
>
> -static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> -static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> -
> static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> enum drm_bridge_attach_flags flags)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> - return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> -}
> -
> -static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> -{
> - struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> -
> - mtk_dsi_destroy_conn_enc(dsi);
> + /* Attach the panel or bridge to the dsi bridge */
> + return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
> +&dsi->bridge, flags);
> }
>
> static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
> @@ -830,115 +779,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge
> *bridge)
> mtk_output_dsi_enable(dsi);
> }
>
> -static int mtk_dsi_connecto
Re: [Nouveau] [PATCH] drm/nouveau/dispnv04: Remove dead code
On Fri, May 1, 2020 at 9:15 AM Souptick Joarder wrote: > > On Fri, May 1, 2020 at 2:21 AM Ilia Mirkin wrote: > > > > Interesting. I do remember seeing some snow on NV5's overlay at high > > resolutions. Wonder if it was because of this missing code... > > What was the problem ? Does enabling this dead code will fix the problem ? This "dead" code is essentially documentation. It's from the xf86-video-nv driver which was the base of the dispnv04 code. It won't compile as-is, which is why it's #if 0'd out. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/10] Generic USB Display driver
Den 29.04.2020 14.48, skrev Noralf Trønnes: > Hi, > > A while back I had the idea to turn a Raspberry Pi Zero into a $5 > USB to HDMI/SDTV/DSI/DPI display adapter. > > This series adds a USB host driver and a device/gadget driver to achieve > that. > > The reason for calling it 'Generic' is so anyone can make a USB > display/adapter against this driver, all that's needed is to add a USB > vid:pid. I was hoping to have someone working on a microcontroller based > USB display by now, but unfortunately that has been delayed. It would > have been nice to have a microcontroller implementation to ensure that I > haven't made things unnecessary difficult to implement. > > Performance > The one thing that decides how useful this all is, is how smooth an > experience it gives. My hope was that it should not be noticeably laggy > with ordinary office use on 1920x1080@RG16. I'm pleased to see that it's > also possible to watch youtube movies, although not in fullscreen. > > Some of the main factors that affects performance: > - Display resolution > - Userspace providing damage reports (FB_DAMAGE_CLIPS or > DRM_IOCTL_MODE_DIRTYFB) > - Color depth (DRM_CAP_DUMB_PREFERRED_DEPTH = 16 if RGB565) > - How well the frames compress (lz4) > - Gadget device memory bandwidth, CPU power for decompression > - (Big endian hosts will have to do byte swapping on the frames) One factor that I forgot is USB2 vs USB3. The Pi's have a USB2 Device controller (dwc2). I couldn't find a cheap board with a USB3 Device controller that could run mainline Linux, so I haven't tried that. > > I've tested these: > - xorg-server on Pi4. This was nice and smooth since it uses > DRM_IOCTL_MODE_DIRTYFB and honours DRM_CAP_DUMB_PREFERRED_DEPTH. > - Ubuntu 20.04 GNOME on x86. This was useable, but not so good for > movies. GNOME doesn't look at DRM_CAP_DUMB_PREFERRED_DEPTH and doesn't > set FB_DAMAGE_CLIPS on the pageflips. > > I've made a short video to show what it looks like[1]. I got a question if this would work with usbip[4], USB over IP. I did a quick test with two Pi4's connected by cable to the same network switch (1Gb). Showing a movie in a window like my previous test didn't show much of a difference. Maybe some occasional glitching, hard to tell without proper tests. There's no pageflipping on the device side, so it could be tearing that I saw. Noralf. [4] tools/usb/usbip/README > > I have used a Pi4 as the gadget during development since it has much > better memory bandwith (4000 vs 200 MBps)[2] and CPU than the PiZ. They > both have the same gadget controller (dwc2). > > I did an RFC [3] of this 2 months ago where I looked at doing a Multi > Function USB device. I gave up on that when I realised how much work the > review process would be. So I stripped down to my original idea. I have > made sure that the drivers will tolerate another USB interface of type > VENDOR, so it's still possible for the display to be part of a multi > function device. > > Noralf. > > [1] https://youtu.be/AhGZWwUm8JU > [2] https://magpi.raspberrypi.org/articles/raspberry-pi-specs-benchmarks > [3] https://patchwork.freedesktop.org/series/73508/ > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/7] drm/mediatek: mtk_dsi: Use simple encoder
Hi, Enric:
Enric Balletbo i Serra 於 2020年4月17日 週五 下午11:06寫道：
>
> The mtk_dsi driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Enric Balletbo i Serra
> Reviewed-by: Laurent Pinchart
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 869ae0a2e9f8..d68694ff00dc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk_drm_ddp_comp.h"
>
> @@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> dsi->enabled = false;
> }
>
> -static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
> -{
> - drm_encoder_cleanup(encoder);
> -}
> -
> -static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
> - .destroy = mtk_dsi_encoder_destroy,
> -};
> -
> static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
>
> @@ -1140,8 +1132,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
> struct mtk_dsi *dsi)
> {
> int ret;
>
> - ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
> - DRM_MODE_ENCODER_DSI, NULL);
> + ret = drm_simple_encoder_init(drm, &dsi->encoder,
> + DRM_MODE_ENCODER_DSI);
> if (ret) {
> DRM_ERROR("Failed to encoder init to drm\n");
> return ret;
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: Don't check new mode if CRTC is being disabled
Hi Thomas, Couple of fly-by ideas/suggestions. On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann wrote: > > Suspending failed because there's no mode if the CRTC is being > disabled. Early-out in this case. This fixes runtime PM for ast. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/ast/ast_mode.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > index 7a9f20a2fd303..089b7d9a0cf3f 100644 > --- a/drivers/gpu/drm/ast/ast_mode.c > +++ b/drivers/gpu/drm/ast/ast_mode.c > @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc > *crtc, > return -EINVAL; Unrelated: This feels quite dirty. If AST1180 does not support atomic modeset simply remove the DRIVER_ATOMIC bit. You can do that at runtime, via drm_device::driver_features in say, ast_detect_chip()? The drm_driver::driver_features is immutable, or it ought to be. > } > > + if (!state->enable) > + return 0; /* no checks required if CRTC is being disabled */ > + I cannot think of a reason why a driver would need to perform crtc_atomic_check, if the crtc is being disabled. Can you spot any? If not, this should be better served in core, which calls this callback. Correct? HTH -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver
Hi, Enric:
Enric Balletbo i Serra 於 2020年4月17日 週五 下午11:06寫道：
>
> Convert mtk_dsi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v3:
> - Add the bridge.type. (Laurent Pinchart)
>
> Changes in v2: None
>
> drivers/gpu/drm/mediatek/mtk_dsi.c | 93 ++
> 1 file changed, 69 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 37b8d7ffd835..869ae0a2e9f8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -180,6 +180,7 @@ struct mtk_dsi {
> struct device *dev;
> struct mipi_dsi_host host;
> struct drm_encoder encoder;
> + struct drm_bridge bridge;
> struct drm_connector conn;
> struct drm_panel *panel;
> struct drm_bridge *next_bridge;
> @@ -205,9 +206,9 @@ struct mtk_dsi {
> const struct mtk_dsi_driver_data *driver_data;
> };
>
> -static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> +static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
> {
> - return container_of(e, struct mtk_dsi, encoder);
> + return container_of(b, struct mtk_dsi, bridge);
> }
>
> static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
> @@ -796,32 +797,43 @@ static const struct drm_encoder_funcs
> mtk_dsi_encoder_funcs = {
> .destroy = mtk_dsi_encoder_destroy,
> };
>
> -static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
> *dsi);
> +static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
> +
> +static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
> +enum drm_bridge_attach_flags flags)
> +{
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> + return mtk_dsi_create_conn_enc(bridge->dev, dsi);
> +}
> +
> +static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
> {
> - return true;
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> +
> + mtk_dsi_destroy_conn_enc(dsi);
> }
>
> -static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted)
> +static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> drm_display_mode_to_videomode(adjusted, &dsi->vm);
> }
>
> -static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_disable(dsi);
> }
>
> -static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
> +static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
> {
> - struct mtk_dsi *dsi = encoder_to_dsi(encoder);
> + struct mtk_dsi *dsi = bridge_to_dsi(bridge);
>
> mtk_output_dsi_enable(dsi);
> }
> @@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct
> drm_connector *connector)
> return drm_panel_get_modes(dsi->panel, connector);
> }
>
> -static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
> - .mode_fixup = mtk_dsi_encoder_mode_fixup,
> - .mode_set = mtk_dsi_encoder_mode_set,
> - .disable = mtk_dsi_encoder_disable,
> - .enable = mtk_dsi_encoder_enable,
> +static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
> + .attach = mtk_dsi_bridge_attach,
> + .detach = mtk_dsi_bridge_detach,
> + .disable = mtk_dsi_bridge_disable,
> + .enable = mtk_dsi_bridge_enable,
> + .mode_set = mtk_dsi_bridge_mode_set,
> };
>
> static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
> @@ -1123,6 +1136,34 @@ static const struct mipi_dsi_host_ops mtk_dsi_ops = {
> .transfer = mtk_dsi_host_transfer,
> };
>
> +static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> +{
> + int ret;
> +
> + ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
> + DRM_MODE_ENCODER_DSI, NULL);
I'm a bit confused here. drm_encoder_init() exist here and in
mtk_dsi_create_conn_enc(). Do you plan to init encodr twice?
> + if (ret) {
> + DRM_ERROR("Failed to encoder init to
Re: [PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341
On Thu, 2020-04-30 at 17:43 +0800, dillon.min...@gmail.com wrote:
> From: dillon min
>
> Signed-off-by: dillon min
> ---
> .../bindings/display/panel/ilitek,ili9341.txt | 42 +++
> arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 79
> +++
> arch/arm/boot/dts/stm32f429-disco.dts | 88
> ++
> arch/arm/boot/dts/stm32f429.dtsi | 12 +++
> 4 files changed, 221 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> new file mode 100644
> index 000..f5a4e55
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> @@ -0,0 +1,42 @@
> +Ilitek ILI9341 TFT panel driver with SPI control bus
> +
> +This is a driver for 240x320 TFT panels, accepting a rgb input
> +streams that get adapted and scaled to the panel.
> +
> +Required properties:
> + - compatible: "stm32f429-disco,ltdc-panel", "ilitek,ili9341"
> +(full system-specific compatible is always required to look up
> configuration)
> + - reg: address of the panel on the SPI bus
> +
> +Optional properties:
> + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
> + - dc-gpios: a GPIO spec for the dc pin, see gpio/gpio.txt
> +
> + The following optional properties only apply to RGB input mode:
> +
> + - pixelclk-active: see display/panel/display-timing.txt
> + - de-active: see display/panel/display-timing.txt
> + - hsync-active: see display/panel/display-timing.txt
> + - vsync-active: see display/panel/display-timing.txt
> +
> +The panel must obey the rules for a SPI slave device as specified in
> +spi/spi-bus.txt
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in
> +media/video-interfaces.txt. This node should describe panel's video
> bus.
> +
> +Example:
> +
> +panel: display@0 {
> + compatible = "stm32f429-disco,ltdc-panel", "ilitek,ili9341";
> + reg = <0>;
> + spi-3wire;
> + spi-max-frequency = <1000>;
> + dc-gpios = <&gpiod 13 0>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&display_out>;
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> index 392fa14..45b68f4 100644
> --- a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> @@ -316,6 +316,85 @@
> };
> };
>
> + ltdc_pins_f429_disco: ltdc-1 {
> + pins {
> + pinmux = 6, AF14)>,
> + /* LCD_HSYNC */
> + 4, AF14)>,
> + /* LCD_VSYNC */
> + 7, AF14)>,
> + /* LCD_CLK */
> + AF14)>,
> + /* LCD_R2 */
> + 0, AF9)>,
> + /* LCD_R3 */
> + AF14)>,
> + /* LCD_R4 */
> + AF14)>,
> + /* LCD_R5 */
> + 1, AF9)>,
> + /* LCD_R6*/
> + 6, AF14)>,
> + /* LCD_R7 */
> + 6, AF14)>,
> + /* LCD_G2 */
> + AF9)>,
> + /* LCD_G3 */
> + AF14)>,
> + /* LCD_G4 */
> + 6, AF14)>,
> + /* LCD_B2 */
> + AF14)>,
> + /* LCD_B3*/
> + AF14)>,
> + /* LCD_G5 */
> + 7, AF14)>,
> + /* LCD_G6 */
> + 3, AF14)>,
> + /* LCD_G7 */
> + AF9)>,
> +
Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
On 2020-05-01 11:21 am, Brian Starkey wrote:
Hi John,
On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wrote:
This patch reworks the cma_heap initialization so that
we expose both the default CMA region and any CMA regions
tagged with "linux,cma-heap" in the device-tree.
Cc: Rob Herring
Cc: Sumit Semwal
Cc: "Andrew F. Davis"
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Pratik Patel
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Sandeep Patil
Cc: Hridya Valsaraju
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Andrew Morton
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux...@kvack.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 626cf7fd033a..dd154e2db101 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
{
struct cma_heap *cma_heap;
struct dma_heap_export_info exp_info;
+ struct cma *default_cma = dev_get_cma_area(NULL);
+
+ /* We only add the default heap and explicitly tagged heaps */
+ if (cma != default_cma && !cma_dma_heap_enabled(cma))
+ return 0;
Thinking about the pl111 thread[1], I'm wondering if we should also
let drivers call this directly to expose their CMA pools, even if they
aren't tagged for dma-heaps in DT. But perhaps that's too close to
policy.
That sounds much like what my first thoughts were - apologies if I'm
wildly off-base here, but as far as I understand:
- Device drivers know whether they have their own "memory-region" or not.
- Device drivers already have to do *something* to participate in dma-buf.
- Device drivers know best how they make use of both the above.
- Therefore couldn't it be left to drivers to choose whether to register
their CMA regions as heaps, without having to mess with DT at all?
Robin.
Cheers,
-Brian
[1] https://lists.freedesktop.org/archives/dri-devel/2020-April/264358.html
cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL);
if (!cma_heap)
@@ -162,16 +167,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
return 0;
}
-static int add_default_cma_heap(void)
+static int cma_heaps_init(void)
{
- struct cma *default_cma = dev_get_cma_area(NULL);
- int ret = 0;
-
- if (default_cma)
- ret = __add_cma_heap(default_cma, NULL);
-
- return ret;
+ cma_for_each_area(__add_cma_heap, NULL);
+ return 0;
}
-module_init(add_default_cma_heap);
+module_init(cma_heaps_init);
MODULE_DESCRIPTION("DMA-BUF CMA Heap");
MODULE_LICENSE("GPL v2");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 2/4] mm: cma: Add dma_heap flag to cma structure
On Fri, May 01, 2020 at 07:39:47AM +, John Stultz wrote:
> This patch adds a dma_heap flag on the cma structure,
> along with accessors to set and read the flag.
>
> This is then used to process and store the "linux,cma-heap"
> property documented in the previous patch.
>
> Cc: Rob Herring
> Cc: Sumit Semwal
> Cc: "Andrew F. Davis"
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hridya Valsaraju
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: Andrew Morton
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux...@kvack.org
> Signed-off-by: John Stultz
> ---
> include/linux/cma.h | 3 +++
> kernel/dma/contiguous.c | 3 +++
> mm/cma.c| 11 +++
> mm/cma.h| 1 +
> 4 files changed, 18 insertions(+)
>
> diff --git a/include/linux/cma.h b/include/linux/cma.h
> index 6ff79fefd01f..d8b8e6ce221c 100644
> --- a/include/linux/cma.h
> +++ b/include/linux/cma.h
> @@ -25,6 +25,9 @@ extern phys_addr_t cma_get_base(const struct cma *cma);
> extern unsigned long cma_get_size(const struct cma *cma);
> extern const char *cma_get_name(const struct cma *cma);
>
> +extern void __init cma_enable_dma_heap(struct cma *cma, bool enabled);
> +extern bool cma_dma_heap_enabled(struct cma *cma);
> +
> extern int __init cma_declare_contiguous_nid(phys_addr_t base,
> phys_addr_t size, phys_addr_t limit,
> phys_addr_t alignment, unsigned int order_per_bit,
> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
> index 8bc6f2d670f9..f667fd51daa2 100644
> --- a/kernel/dma/contiguous.c
> +++ b/kernel/dma/contiguous.c
> @@ -303,6 +303,7 @@ static int __init rmem_cma_setup(struct reserved_mem
> *rmem)
> phys_addr_t mask = align - 1;
> unsigned long node = rmem->fdt_node;
> bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
> + bool heap_exported = of_get_flat_dt_prop(node, "linux,cma-heap", NULL);
> struct cma *cma;
> int err;
>
> @@ -332,6 +333,8 @@ static int __init rmem_cma_setup(struct reserved_mem
> *rmem)
> if (default_cma)
> dma_contiguous_set_default(cma);
>
> + cma_enable_dma_heap(cma, heap_exported);
> +
> rmem->ops = &rmem_cma_ops;
> rmem->priv = cma;
>
> diff --git a/mm/cma.c b/mm/cma.c
> index 0463ad2ce06b..ec671bd8f66e 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -55,6 +55,16 @@ const char *cma_get_name(const struct cma *cma)
> return cma->name ? cma->name : "(undefined)";
> }
>
> +void __init cma_enable_dma_heap(struct cma *cma, bool enabled)
> +{
> + cma->dma_heap = enabled;
> +}
> +
> +bool cma_dma_heap_enabled(struct cma *cma)
> +{
> + return !!cma->dma_heap;
Stylistic thing, but I don't think the !! is really necessary. It's
already a bool anyway.
> +}
> +
> static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>unsigned int align_order)
> {
> @@ -157,6 +167,7 @@ static int __init cma_init_reserved_areas(void)
> }
> core_initcall(cma_init_reserved_areas);
>
> +
nit: spurious newline
Cheers,
-Brian
> /**
> * cma_init_reserved_mem() - create custom contiguous area from reserved
> memory
> * @base: Base address of the reserved area
> diff --git a/mm/cma.h b/mm/cma.h
> index 33c0b517733c..6fe2242c724f 100644
> --- a/mm/cma.h
> +++ b/mm/cma.h
> @@ -13,6 +13,7 @@ struct cma {
> spinlock_t mem_head_lock;
> #endif
> const char *name;
> + bool dma_heap;
> };
>
> extern struct cma cma_areas[MAX_CMA_AREAS];
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 1/4] devicetree: bindings: Add linux,cma-heap tag for reserved memory
Hi, On Fri, May 01, 2020 at 07:39:46AM +, John Stultz wrote: > This patch adds a linux,cma-heap property for CMA reserved memory > regions, which will be used to allow the region to be exposed via > the DMA-BUF Heaps interface > > Cc: Rob Herring > Cc: Sumit Semwal > Cc: "Andrew F. Davis" > Cc: Benjamin Gaignard > Cc: Liam Mark > Cc: Pratik Patel > Cc: Laura Abbott > Cc: Brian Starkey > Cc: Chenbo Feng > Cc: Alistair Strachan > Cc: Sandeep Patil > Cc: Hridya Valsaraju > Cc: Christoph Hellwig > Cc: Marek Szyprowski > Cc: Robin Murphy > Cc: Andrew Morton > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux...@kvack.org > Signed-off-by: John Stultz > --- > .../devicetree/bindings/reserved-memory/reserved-memory.txt| 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > index bac4afa3b197..e97b6a4c3bc0 100644 > --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > @@ -68,6 +68,9 @@ Linux implementation note: > - If a "linux,cma-default" property is present, then Linux will use the >region for the default pool of the contiguous memory allocator. > > +- If a "linux,cma-heap" property is present, then Linux will expose the > + the CMA region via the DMA-BUF Heaps interface. > + Would it be useful or even possible to give some indication of what the heap will end up being called? I'm afraid I don't remember what if any conclusions came out of previous discussions on UAPI for heap enumeration. I suppose CMA names haven't been relevant to userspace before, but they perhaps would be with this change. Alternatively, leaving it effectively undefined doesn't tie us down, and something like links in sysfs can be added as a richer API in the future. Cheers, -Brian > - If a "linux,dma-default" property is present, then Linux will use the >region for the default pool of the consistent DMA allocator. > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] arm64: dts: qcom: sc7180: Add A618 gpu dt blob
This patch adds the required dt nodes and properties
to enabled A618 GPU.
Signed-off-by: Sharat Masetty
---
* Remove GCC_DDRSS_GPU_AXI_CLK clock reference from gpu smmu node.
arch/arm64/boot/dts/qcom/sc7180.dtsi | 102 +++
1 file changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 4216b57..de9a054 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1373,6 +1373,108 @@
};
};
+ gpu: gpu@500 {
+ compatible = "qcom,adreno-618.0", "qcom,adreno";
+ #stream-id-cells = <16>;
+ reg = <0 0x0500 0 0x4>, <0 0x0509e000 0 0x1000>,
+ <0 0x05061000 0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory", "cx_mem", "cx_dbgc";
+ interrupts = ;
+ iommus = <&adreno_smmu 0>;
+ operating-points-v2 = <&gpu_opp_table>;
+ qcom,gmu = <&gmu>;
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-level =
;
+ };
+
+ opp-65000 {
+ opp-hz = /bits/ 64 <65000>;
+ opp-level =
;
+ };
+
+ opp-56500 {
+ opp-hz = /bits/ 64 <56500>;
+ opp-level = ;
+ };
+
+ opp-43000 {
+ opp-hz = /bits/ 64 <43000>;
+ opp-level =
;
+ };
+
+ opp-35500 {
+ opp-hz = /bits/ 64 <35500>;
+ opp-level = ;
+ };
+
+ opp-26700 {
+ opp-hz = /bits/ 64 <26700>;
+ opp-level =
;
+ };
+
+ opp-18000 {
+ opp-hz = /bits/ 64 <18000>;
+ opp-level =
;
+ };
+ };
+ };
+
+ adreno_smmu: iommu@504 {
+ compatible = "qcom,sc7180-smmu-v2", "qcom,smmu-v2";
+ reg = <0 0x0504 0 0x1>;
+ #iommu-cells = <1>;
+ #global-interrupts = <2>;
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+
+ clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gcc GCC_GPU_CFG_AHB_CLK>;
+ clock-names = "bus", "iface";
+
+ power-domains = <&gpucc CX_GDSC>;
+ };
+
+ gmu: gmu@506a000 {
+ compatible="qcom,adreno-gmu-618.0", "qcom,adreno-gmu";
+ reg = <0 0x0506a000 0 0x31000>, <0 0x0b29 0
0x1>,
+ <0 0x0b49 0 0x1>;
+ reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+ interrupts = ,
+ ;
+ interrupt-names = "hfi", "gmu";
+ clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "gmu", "cxo", "axi", "memnoc";
+ power-domains = <&gpucc CX_GDSC>, <&gpucc GX_GDSC>;
+ power-domain-names = "cx", "gx";
+ iommus = <&adreno_smmu 5>;
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+
[PATCH 2/2] dt-bindings: arm-smmu: Add sc7180 compatible string
This patch simply adds a new compatible string for SC7180 platform. Signed-off-by: Sharat Masetty --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 6515dbe..986098b 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -28,6 +28,7 @@ properties: - enum: - qcom,msm8996-smmu-v2 - qcom,msm8998-smmu-v2 + - qcom,sc7180-smmu-v2 - qcom,sdm845-smmu-v2 - const: qcom,smmu-v2 -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"
Hi John,
On Fri, May 01, 2020 at 07:39:48AM +, John Stultz wrote:
> This patch reworks the cma_heap initialization so that
> we expose both the default CMA region and any CMA regions
> tagged with "linux,cma-heap" in the device-tree.
>
> Cc: Rob Herring
> Cc: Sumit Semwal
> Cc: "Andrew F. Davis"
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Pratik Patel
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Chenbo Feng
> Cc: Alistair Strachan
> Cc: Sandeep Patil
> Cc: Hridya Valsaraju
> Cc: Christoph Hellwig
> Cc: Marek Szyprowski
> Cc: Robin Murphy
> Cc: Andrew Morton
> Cc: devicet...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux...@kvack.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/cma_heap.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 626cf7fd033a..dd154e2db101 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
> {
> struct cma_heap *cma_heap;
> struct dma_heap_export_info exp_info;
> + struct cma *default_cma = dev_get_cma_area(NULL);
> +
> + /* We only add the default heap and explicitly tagged heaps */
> + if (cma != default_cma && !cma_dma_heap_enabled(cma))
> + return 0;
Thinking about the pl111 thread[1], I'm wondering if we should also
let drivers call this directly to expose their CMA pools, even if they
aren't tagged for dma-heaps in DT. But perhaps that's too close to
policy.
Cheers,
-Brian
[1] https://lists.freedesktop.org/archives/dri-devel/2020-April/264358.html
>
> cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL);
> if (!cma_heap)
> @@ -162,16 +167,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
> return 0;
> }
>
> -static int add_default_cma_heap(void)
> +static int cma_heaps_init(void)
> {
> - struct cma *default_cma = dev_get_cma_area(NULL);
> - int ret = 0;
> -
> - if (default_cma)
> - ret = __add_cma_heap(default_cma, NULL);
> -
> - return ret;
> + cma_for_each_area(__add_cma_heap, NULL);
> + return 0;
> }
> -module_init(add_default_cma_heap);
> +module_init(cma_heaps_init);
> MODULE_DESCRIPTION("DMA-BUF CMA Heap");
> MODULE_LICENSE("GPL v2");
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #31 from Matthias Heinz (m...@familie-heinz.name) --- Hi, for me this bug is fixed with a 5.5 kernel. And I'm wondering if this is fixed for all of you, too. Best Matthias -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #8 from Duncan (1i5t5.dun...@cox.net) --- Hmm. Don't think I mentioned on this bug yet that I'm running dual 4K TVs as monitors. So it could only trigger on dual display, and two 4K displays means it's pumping a lot more pixels than most cards, too. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7-rc: amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #7 from Duncan (1i5t5.dun...@cox.net) --- Bisecting, but it's slow going when the bug can take 12+ hours to trigger, and even then I can't be sure a "good" is actually so. So far (at 5.6.0-01623-g12ab316ce, ~7 bisect steps to go, under 100 commits "after"), the first few were all "good", while the one I'm currently testing obviously isn't "bad" in terms of this bug yet, but does display a nasty buffer-sync issue with off-frame read-outs and eventual firefox crashes trying to play 4k@30fps youtube in firefox, a bit of a struggle with this kit but usually OK (it's the 4k@60fps that's the real problem in firefox/chromium, tho it tends to be fine without the browser overhead in mpv/smplayer/vlc). But I hadn't seen that issue with the full 5.7-rc1 thru rc3, so it was apparently already fixed with rc1. And no incidents of this bug, full system or full graphics lockups with a segfault in amdgpu_dm_atomic_commit_tail, during the bisect yet. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v2] dt-bindings: arm-smmu: Add sc7180 compatible string and mem_iface clock
On 4/30/2020 11:51 PM, Doug Anderson wrote: Hi, On Thu, Apr 30, 2020 at 11:12 AM Jordan Crouse wrote: On Thu, Apr 30, 2020 at 09:29:47AM +0530, Sharat Masetty wrote: This patch adds a new compatible string for sc7180 and also an additional clock listing needed to power the TBUs and the TCU. Signed-off-by: Sharat Masetty --- v2: Addressed review comments from Doug Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 6515dbe..ba5dba4 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -28,6 +28,7 @@ properties: - enum: - qcom,msm8996-smmu-v2 - qcom,msm8998-smmu-v2 + - qcom,sc7180-smmu-v2 - qcom,sdm845-smmu-v2 - const: qcom,smmu-v2 @@ -113,16 +114,23 @@ properties: present in such cases. clock-names: +minItems: 2 +maxItems: 3 items: - const: bus - const: iface + - const: mem_iface Hi Sharat - I think there was a bit of confusion due to renaming between downstream and upstream. Currently for the sdm845 and friends we have: clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>, <&gcc GCC_GPU_CFG_AHB_CLK>; clock-names = "bus", "iface"; Confusingly these same clocks downstream are "mem_iface_clk" and "iface_clk" respectively. It looks like you are trying to add GCC_DDRSS_GPU_AXI_CLK as "mem_iface" which was formerly "mem_clk" downstream. I'm not sure if the naming change is intentional or you were trying to make upstream and downstream match and didn't realize that they were renamed. I'm not sure if we need DDRSS_GPU_AXI_CLK or not. Empirically it works without it for sdm845 (I don't have a sc7180 to test) but we should probably loop back with either the clock team or the hardware designers to be sure there isn't a corner case that is missing. I agree with Doug that its always best if we don't need to add a clock. Thanks Jordan and Doug for the updates. My intention was to add the third clock as listed downstream, but as you said the naming is a bit misleading. From the clock GCC_DDRSS_GPU_AXI_CLK description, this is needed for the GPU to DDR access and all transactions to the DDR from the GPU go through the SMMU. It is listed in the SMMU dt node because its needed by SMMU to perform pagetable walks. I think we may be fine by not listing this clock in the SMMU node because the same clock is listed in both the GMU and also the GPU. I can confirm that on sc7180 the GPU seems to come up just fine without the clock being specified in the iommu node. Definitely would be good to know what's broken and if nothing is broken maybe we can change this patch to just add the sc7180 compatible string and drop the clock. I do note that the GMU already has a reference to the same "GCC_DDRSS_GPU_AXI_CLK" clock. -Doug ___ Freedreno mailing list freedr...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 4/4] example: dts: hi3660-hikey960: Add dts entries to test cma heap binding
Adds example test entry to create and expose a dummy "camera"
cma region via the dmabuf heaps interface
This isn't a patch I'm submitting to merge, but just an example
of how this functionality can be used, which I've used for
testing.
Cc: Rob Herring
Cc: Sumit Semwal
Cc: "Andrew F. Davis"
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Pratik Patel
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Sandeep Patil
Cc: Hridya Valsaraju
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Andrew Morton
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux...@kvack.org
Signed-off-by: John Stultz
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index c0a6aad9593f..5eef1a76d51a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -81,6 +81,13 @@
reusable;
linux,cma-default;
};
+
+ cma_camera: cma-camera {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x24C0 0x0 0x400>;
+ reusable;
+ linux,cma-heap;
+ };
};
reboot-mode-syscon@3210 {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 2/4] mm: cma: Add dma_heap flag to cma structure
This patch adds a dma_heap flag on the cma structure,
along with accessors to set and read the flag.
This is then used to process and store the "linux,cma-heap"
property documented in the previous patch.
Cc: Rob Herring
Cc: Sumit Semwal
Cc: "Andrew F. Davis"
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Pratik Patel
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Sandeep Patil
Cc: Hridya Valsaraju
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Andrew Morton
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux...@kvack.org
Signed-off-by: John Stultz
---
include/linux/cma.h | 3 +++
kernel/dma/contiguous.c | 3 +++
mm/cma.c| 11 +++
mm/cma.h| 1 +
4 files changed, 18 insertions(+)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 6ff79fefd01f..d8b8e6ce221c 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -25,6 +25,9 @@ extern phys_addr_t cma_get_base(const struct cma *cma);
extern unsigned long cma_get_size(const struct cma *cma);
extern const char *cma_get_name(const struct cma *cma);
+extern void __init cma_enable_dma_heap(struct cma *cma, bool enabled);
+extern bool cma_dma_heap_enabled(struct cma *cma);
+
extern int __init cma_declare_contiguous_nid(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 8bc6f2d670f9..f667fd51daa2 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -303,6 +303,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
phys_addr_t mask = align - 1;
unsigned long node = rmem->fdt_node;
bool default_cma = of_get_flat_dt_prop(node, "linux,cma-default", NULL);
+ bool heap_exported = of_get_flat_dt_prop(node, "linux,cma-heap", NULL);
struct cma *cma;
int err;
@@ -332,6 +333,8 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
if (default_cma)
dma_contiguous_set_default(cma);
+ cma_enable_dma_heap(cma, heap_exported);
+
rmem->ops = &rmem_cma_ops;
rmem->priv = cma;
diff --git a/mm/cma.c b/mm/cma.c
index 0463ad2ce06b..ec671bd8f66e 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -55,6 +55,16 @@ const char *cma_get_name(const struct cma *cma)
return cma->name ? cma->name : "(undefined)";
}
+void __init cma_enable_dma_heap(struct cma *cma, bool enabled)
+{
+ cma->dma_heap = enabled;
+}
+
+bool cma_dma_heap_enabled(struct cma *cma)
+{
+ return !!cma->dma_heap;
+}
+
static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
unsigned int align_order)
{
@@ -157,6 +167,7 @@ static int __init cma_init_reserved_areas(void)
}
core_initcall(cma_init_reserved_areas);
+
/**
* cma_init_reserved_mem() - create custom contiguous area from reserved memory
* @base: Base address of the reserved area
diff --git a/mm/cma.h b/mm/cma.h
index 33c0b517733c..6fe2242c724f 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -13,6 +13,7 @@ struct cma {
spinlock_t mem_head_lock;
#endif
const char *name;
+ bool dma_heap;
};
extern struct cma cma_areas[MAX_CMA_AREAS];
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 1/4] devicetree: bindings: Add linux, cma-heap tag for reserved memory
This patch adds a linux,cma-heap property for CMA reserved memory regions, which will be used to allow the region to be exposed via the DMA-BUF Heaps interface Cc: Rob Herring Cc: Sumit Semwal Cc: "Andrew F. Davis" Cc: Benjamin Gaignard Cc: Liam Mark Cc: Pratik Patel Cc: Laura Abbott Cc: Brian Starkey Cc: Chenbo Feng Cc: Alistair Strachan Cc: Sandeep Patil Cc: Hridya Valsaraju Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: Andrew Morton Cc: devicet...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux...@kvack.org Signed-off-by: John Stultz --- .../devicetree/bindings/reserved-memory/reserved-memory.txt| 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt index bac4afa3b197..e97b6a4c3bc0 100644 --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt @@ -68,6 +68,9 @@ Linux implementation note: - If a "linux,cma-default" property is present, then Linux will use the region for the default pool of the contiguous memory allocator. +- If a "linux,cma-heap" property is present, then Linux will expose the + the CMA region via the DMA-BUF Heaps interface. + - If a "linux,dma-default" property is present, then Linux will use the region for the default pool of the consistent DMA allocator. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 0/4] Support non-default CMA regions to the dmabuf heaps interface
This is a much belated second stab at allowing non-default CMA regions to be exposed via the dmabuf heaps interface. Previous attempt was here: https://lore.kernel.org/lkml/20191025225009.50305-2-john.stu...@linaro.org/T/ This pass tried to take Rob's earlier suggestion to use a flag property. Feedback would be greatly welcome! thanks -john Cc: Rob Herring Cc: Sumit Semwal Cc: "Andrew F. Davis" Cc: Benjamin Gaignard Cc: Liam Mark Cc: Pratik Patel Cc: Laura Abbott Cc: Brian Starkey Cc: Chenbo Feng Cc: Alistair Strachan Cc: Sandeep Patil Cc: Hridya Valsaraju Cc: Christoph Hellwig Cc: Marek Szyprowski Cc: Robin Murphy Cc: Andrew Morton Cc: devicet...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux...@kvack.org John Stultz (4): devicetree: bindings: Add linux,cma-heap tag for reserved memory mm: cma: Add dma_heap flag to cma structure dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap" example: dts: hi3660-hikey960: Add dts entries to test cma heap binding .../reserved-memory/reserved-memory.txt| 3 +++ .../boot/dts/hisilicon/hi3660-hikey960.dts | 7 +++ drivers/dma-buf/heaps/cma_heap.c | 18 +- include/linux/cma.h| 3 +++ kernel/dma/contiguous.c| 3 +++ mm/cma.c | 11 +++ mm/cma.h | 1 + 7 files changed, 37 insertions(+), 9 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux, cma-heap"
This patch reworks the cma_heap initialization so that
we expose both the default CMA region and any CMA regions
tagged with "linux,cma-heap" in the device-tree.
Cc: Rob Herring
Cc: Sumit Semwal
Cc: "Andrew F. Davis"
Cc: Benjamin Gaignard
Cc: Liam Mark
Cc: Pratik Patel
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc: Sandeep Patil
Cc: Hridya Valsaraju
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Robin Murphy
Cc: Andrew Morton
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux...@kvack.org
Signed-off-by: John Stultz
---
drivers/dma-buf/heaps/cma_heap.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c
index 626cf7fd033a..dd154e2db101 100644
--- a/drivers/dma-buf/heaps/cma_heap.c
+++ b/drivers/dma-buf/heaps/cma_heap.c
@@ -141,6 +141,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
{
struct cma_heap *cma_heap;
struct dma_heap_export_info exp_info;
+ struct cma *default_cma = dev_get_cma_area(NULL);
+
+ /* We only add the default heap and explicitly tagged heaps */
+ if (cma != default_cma && !cma_dma_heap_enabled(cma))
+ return 0;
cma_heap = kzalloc(sizeof(*cma_heap), GFP_KERNEL);
if (!cma_heap)
@@ -162,16 +167,11 @@ static int __add_cma_heap(struct cma *cma, void *data)
return 0;
}
-static int add_default_cma_heap(void)
+static int cma_heaps_init(void)
{
- struct cma *default_cma = dev_get_cma_area(NULL);
- int ret = 0;
-
- if (default_cma)
- ret = __add_cma_heap(default_cma, NULL);
-
- return ret;
+ cma_for_each_area(__add_cma_heap, NULL);
+ return 0;
}
-module_init(add_default_cma_heap);
+module_init(cma_heaps_init);
MODULE_DESCRIPTION("DMA-BUF CMA Heap");
MODULE_LICENSE("GPL v2");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 10/10] drm: Remove drm specific kmap_atomic code
Am 30.04.20 um 22:38 schrieb ira.we...@intel.com:
From: Ira Weiny
kmap_atomic_prot() is now exported by all architectures. Use this
function rather than open coding a driver specific kmap_atomic.
Signed-off-by: Ira Weiny
Ah, yes looking into this once more this was on my TODO list for quite a
while as well.
Patch is Reviewed-by: Christian König , feel
free to push it upstream through whatever channel you like or ping me if
I should pick it up into drm-misc-next.
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 16
include/drm/ttm/ttm_bo_api.h | 4 --
3 files changed, 12 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 52d2b71f1588..f09b096ba4fd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -257,54 +257,6 @@ static int ttm_copy_io_page(void *dst, void *src, unsigned
long page)
return 0;
}
-#ifdef CONFIG_X86
-#define __ttm_kmap_atomic_prot(__page, __prot) kmap_atomic_prot(__page, __prot)
-#define __ttm_kunmap_atomic(__addr) kunmap_atomic(__addr)
-#else
-#define __ttm_kmap_atomic_prot(__page, __prot) vmap(&__page, 1, 0, __prot)
-#define __ttm_kunmap_atomic(__addr) vunmap(__addr)
-#endif
-
-
-/**
- * ttm_kmap_atomic_prot - Efficient kernel map of a single page with
- * specified page protection.
- *
- * @page: The page to map.
- * @prot: The page protection.
- *
- * This function maps a TTM page using the kmap_atomic api if available,
- * otherwise falls back to vmap. The user must make sure that the
- * specified page does not have an aliased mapping with a different caching
- * policy unless the architecture explicitly allows it. Also mapping and
- * unmapping using this api must be correctly nested. Unmapping should
- * occur in the reverse order of mapping.
- */
-void *ttm_kmap_atomic_prot(struct page *page, pgprot_t prot)
-{
- if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
- return kmap_atomic(page);
- else
- return __ttm_kmap_atomic_prot(page, prot);
-}
-EXPORT_SYMBOL(ttm_kmap_atomic_prot);
-
-/**
- * ttm_kunmap_atomic_prot - Unmap a page that was mapped using
- * ttm_kmap_atomic_prot.
- *
- * @addr: The virtual address from the map.
- * @prot: The page protection.
- */
-void ttm_kunmap_atomic_prot(void *addr, pgprot_t prot)
-{
- if (pgprot_val(prot) == pgprot_val(PAGE_KERNEL))
- kunmap_atomic(addr);
- else
- __ttm_kunmap_atomic(addr);
-}
-EXPORT_SYMBOL(ttm_kunmap_atomic_prot);
-
static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
unsigned long page,
pgprot_t prot)
@@ -316,13 +268,13 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void
*src,
return -ENOMEM;
src = (void *)((unsigned long)src + (page << PAGE_SHIFT));
- dst = ttm_kmap_atomic_prot(d, prot);
+ dst = kmap_atomic_prot(d, prot);
if (!dst)
return -ENOMEM;
memcpy_fromio(dst, src, PAGE_SIZE);
- ttm_kunmap_atomic_prot(dst, prot);
+ kunmap_atomic(dst);
return 0;
}
@@ -338,13 +290,13 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, void
*dst,
return -ENOMEM;
dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));
- src = ttm_kmap_atomic_prot(s, prot);
+ src = kmap_atomic_prot(s, prot);
if (!src)
return -ENOMEM;
memcpy_toio(dst, src, PAGE_SIZE);
- ttm_kunmap_atomic_prot(src, prot);
+ kunmap_atomic(src);
return 0;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
index bb46ca0c458f..94d456a1d1a9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -374,12 +374,12 @@ static int vmw_bo_cpu_blit_line(struct
vmw_bo_blit_line_data *d,
copy_size = min_t(u32, copy_size, PAGE_SIZE - src_page_offset);
if (unmap_src) {
- ttm_kunmap_atomic_prot(d->src_addr, d->src_prot);
+ kunmap_atomic(d->src_addr);
d->src_addr = NULL;
}
if (unmap_dst) {
- ttm_kunmap_atomic_prot(d->dst_addr, d->dst_prot);
+ kunmap_atomic(d->dst_addr);
d->dst_addr = NULL;
}
@@ -388,8 +388,8 @@ static int vmw_bo_cpu_blit_line(struct vmw_bo_blit_line_data *d,
return -EINVAL;
d->dst_addr =
- ttm_kmap_atomic_prot(d->dst_pages[dst_page],
-d->dst_prot);
+ kmap_atomic_prot(d->dst_pages[dst_page],
+d->dst_prot);
Re: [PATCH v2 05/91] clk: bcm: rpi: Allow the driver to be probed by DT
On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The current firmware clock driver for the RaspberryPi can only be probed by
> manually registering an associated platform_device.
>
> While this works fine for cpufreq where the device gets attached a clkdev
> lookup, it would be tedious to maintain a table of all the devices using
> one of the clocks exposed by the firmware.
>
> Since the DT on the other hand is the perfect place to store those
> associations, make the firmware clocks driver probe-able through the device
> tree so that we can represent it as a node.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Maxime Ripard
> ---
> drivers/clk/bcm/clk-raspberrypi.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-
> raspberrypi.c
> index 1654fd0eedc9..aedeaaf2f66b 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -255,15 +255,22 @@ static int raspberrypi_clk_probe(struct platform_device
> *pdev)
> struct raspberrypi_clk *rpi;
> int ret;
>
> - firmware_node = of_find_compatible_node(NULL, NULL,
> - "raspberrypi,bcm2835-firmware");
> + /*
> + * We can be probed either through the an old-fashioned
> + * platform device registration or through a DT node that is a
> + * child of the firmware node. Handle both cases.
> + */
> + if (dev->of_node)
> + firmware_node = of_get_parent(dev->of_node);
> + else
> + firmware_node = of_find_compatible_node(NULL, NULL,
> + "raspberrypi,bcm2835-
> firmware");
> if (!firmware_node) {
> dev_err(dev, "Missing firmware node\n");
> return -ENOENT;
> }
>
> firmware = rpi_firmware_get(firmware_node);
> - of_node_put(firmware_node);
Why remove this? I think it's still needed after your changes.
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re:Re: [PATCH] drm/radeon: cleanup coding style a bit
发件人：Joe Perches
发送日期：2020-04-27 01:53:06
收件人："Christian König" ,Bernard Zhao
,Alex Deucher ,"David (ChunMing)
Zhou" ,David Airlie ,Daniel Vetter
,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org
抄送人：opensource.ker...@vivo.com
主题：Re: [PATCH] drm/radeon: cleanup coding style a bit>On Sun, 2020-04-26 at
15:18 +0200, Christian König wrote:
>> Am 26.04.20 um 15:12 schrieb Bernard Zhao:
>> > Maybe no need to check ws before kmalloc, kmalloc will check
>> > itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
>> > return
>> >
>> > Signed-off-by: Bernard Zhao
>>
>> Reviewed-by: Christian König
>>
>> I'm wondering why the automated scripts haven't found that one before.
>
>because this pattern is
>
> if (foo)
> kfree(bar);
>
>and the pattern looked for is:
>
> if (foo)
> kfree(foo);
>
>> > diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
>[]
>> > @@ -1211,8 +1211,7 @@ static int atom_execute_table_locked(struct
>> > atom_context *ctx, int index, uint32
>> >SDEBUG("<<\n");
>> >
>> > free:
>> > - if (ws)
>> > - kfree(ectx.ws);
>> > + kfree(ectx.ws);
>> >return ret;
>> > }
>
>I'm wondering if this removal is correct as the function
>is named _locked and it may be recursive or called under
>some external lock.
>
Hi
I am a little confused about this. I understand that the caller guarantees the
lock protection
that we will not release the wrong pointer. And the NULL check is the same with
the first check in kfree?
Maybe we do not need check twich.
Regards,
Bernard
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 00/10] Remove duplicated kmap code
ira.we...@intel.com writes: > From: Ira Weiny > > The kmap infrastructure has been copied almost verbatim to every architecture. > This series consolidates obvious duplicated code by defining core functions > which call into the architectures only when needed. > > Some of the k[un]map_atomic() implementations have some similarities but the > similarities were not sufficient to warrant further changes. > > In addition we remove a duplicate implementation of kmap() in DRM. > > Testing was done by 0day to cover all the architectures I can't readily > build/test. I threw some powerpc builds at it and they all passed, so LGTM. cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Hi Daniel,
On Thu, Apr 30, 2020 at 03:38:39PM +0200, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 03:37:31PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> > > On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > > > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji wrote:
> > > > > >
> > > > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Just commenting on the mode_fixup function that was added in v7.
> > > > > > >
> > > > > > [snip]
> > > > > > > > + /*
> > > > > > > > +* once illegal timing detected, use default HFP,
> > > > > > > > HSYNC, HBP
> > > > > > > > +*/
> > > > > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN && hbp <
> > > > > > > > HP_MIN)) {
> > > > > > >
> > > > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > > > NO, need check original HFP and HBP, if they are not legal, driver
> > > > > > need
> > > > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > > > >
> > > > > > > > + adj_hsync = SYNC_LEN_DEF;
> > > > > > > > + adj_hfp = HFP_HBP_DEF;
> > > > > > > > + adj_hbp = HFP_HBP_DEF;
> > > > > > > > + vref = adj->clock * 1000 / (adj->htotal *
> > > > > > > > adj->vtotal);
> > > > > > > > + if (hblanking < HBLANKING_MIN) {
> > > > > > > > + delta_adj = HBLANKING_MIN - hblanking;
> > > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > > adj->vtotal;
> > > > > > > > + adj->clock += DIV_ROUND_UP(adj_clock,
> > > > > > > > 1000);
> > > > > > > > + } else {
> > > > > > > > + delta_adj = hblanking - HBLANKING_MIN;
> > > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > > adj->vtotal;
> > > > > > > > + adj->clock -= DIV_ROUND_UP(adj_clock,
> > > > > > > > 1000);
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + DRM_WARN("illegal hblanking timing, use
> > > > > > > > default.\n");
> > > > > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n", hfp,
> > > > > > > > hbp, hsync);
> > > > > > >
> > > > > > > How likely is it that this mode is going to work? Can you just
> > > > > > > return
> > > > > > > false here to reject the mode?
> > > > > > We want to set the default minimal Hblancking value, then it may
> > > > > > display,
> > > > > > otherwise. If we just return false, there is no display for sure.
> > > > >
> > > > > Right, understand your argument. I'm pondering if it's not just better
> > > > > to reject the mode rather than trying a timing that is definitely
> > > > > quite different from what the monitor was asking for. No super strong
> > > > > opinion, I'll let other people on the list weigh in.
> > > >
> > > > Yeah mode_fixup is supposed to be used to adjust the mode in
> > > > intermediate
> > > > stages (e.g. if you go from progressive to interlaced only at the end of
> > > > your pipeline or something like that). It's not meant for adjusting the
> > > > mode yout actually put out through a hdmi or dp connector. For fixed
> > > > panels adjusting modes to fit the panel is also fairly common, but not
> > > > for
> > > > external outputs.
> > > >
> > > > Since this is a DP bridge I'd say no adjusting, just reject what doesn't
> > > > fit.
> > > We have found some panel which HBP less than 8, if we reject to adjust
> > > video timing, then there is no display. The customer does not accept it,
> > > they push us to fix it, the only resolve way is to adjust timing.
> >
> > Are we talking about external DP screen here, or some built-in panel? For
> > the later case we do a lot of mode adjusting in many drivers ...
> >
> > I haven't checked, by if our connector type is eDP then this should be all
> > fine.
>
> Ok I read the patch now, you seem to support both. Would it work if we
> make this adjustement conditional on it being an internal panel only? I
> think that would be perfect.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
Based on comments of V8, only keeped eDP built-in panel in V9 version,
removed external DP screen support.
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/91] firmware: rpi: Only create clocks device if we don't have a node for it
On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The firmware clocks driver was previously probed through a platform_device
> created by the firmware driver.
>
> Since we will now have a node for that clocks driver, we need to create the
> device only in the case where there's no node for it already.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/firmware/raspberrypi.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index da26a584dca0..1874f41b007c 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -210,6 +210,15 @@ rpi_register_hwmon_driver(struct device *dev, struct
> rpi_firmware *fw)
>
> static void rpi_register_clk_driver(struct device *dev)
> {
> + /*
> + * Earlier DTs don't have a node for the firmware clocks but
> + * rely on us creating a platform device by hand. If we do
> + * have a node for the firmware clocks, just bail out here.
> + */
> + if (of_get_compatible_child(dev->of_node,
> + "raspberrypi,firmware-clocks"))
In the case you find a compatible device node you have to decrement the
refcount of_get_compatible_child() increased before leaving.
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/mcde: dsi: Fix return value check in mcde_dsi_bind()
> The of_drm_find_bridge() function returns NULL on error, it doesn't return > error pointers so this check doesn't work. How do you think about a wording variant like the following? Change description: An error pointer check was performed after a call of the function “of_drm_find_bridge” despite of the detail that failures are indicated for the bridge search by null pointers instead. Thus adjust a check for the failure predicate and the corresponding exception handling. Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/vboxvideo: Fix a NULL vs IS_ERR() check in vbox_hw_init()
The devm_gen_pool_create() function returns ERR_PTR() on error, it
doesn't return NULL so this check doesn't work.
Fixes: 4cc9b565454b ("drm/vboxvideo: Use devm_gen_pool_create")
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/vboxvideo/vbox_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index d68d9bad7674..c5ea880d17b2 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -123,8 +123,8 @@ int vbox_hw_init(struct vbox_private *vbox)
/* Create guest-heap mem-pool use 2^4 = 16 byte chunks */
vbox->guest_pool = devm_gen_pool_create(vbox->ddev.dev, 4, -1,
"vboxvideo-accel");
- if (!vbox->guest_pool)
- return -ENOMEM;
+ if (IS_ERR(vbox->guest_pool))
+ return PTR_ERR(vbox->guest_pool);
ret = gen_pool_add_virt(vbox->guest_pool,
(unsigned long)vbox->guest_heap,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V1 08/10] arch/kmap: Don't hard code kmap_prot values
On Thu, Apr 30, 2020 at 01:38:43PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > To support kmap_atomic_prot() on all architectures each arch must > support protections passed in to them. > > Change csky, mips, nds32 and xtensa to use their global kmap_prot value > rather than a hard coded value which was equal. Minor nitpick: it's probably worth pointing out that kmap_prot on those is a constant... ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/dispnv04: Remove dead code
These are dead code since 3.10. If there is no plan to use
it further, these can be removed forever.
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 28
1 file changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4..ad0ef7d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -269,31 +269,11 @@ static void nv_crtc_calc_state_ext(struct drm_crtc *crtc,
struct drm_display_mod
horizStart = horizTotal - 5;
horizEnd = horizTotal - 2;
horizBlankEnd = horizTotal + 4;
-#if 0
- if (dev->overlayAdaptor && drm->client.device.info.family >=
NV_DEVICE_INFO_V0_CELSIUS)
- /* This reportedly works around some video overlay
bandwidth problems */
- horizTotal += 2;
-#endif
}
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
vertTotal |= 1;
-#if 0
- ErrorF("horizDisplay: 0x%X \n", horizDisplay);
- ErrorF("horizStart: 0x%X \n", horizStart);
- ErrorF("horizEnd: 0x%X \n", horizEnd);
- ErrorF("horizTotal: 0x%X \n", horizTotal);
- ErrorF("horizBlankStart: 0x%X \n", horizBlankStart);
- ErrorF("horizBlankEnd: 0x%X \n", horizBlankEnd);
- ErrorF("vertDisplay: 0x%X \n", vertDisplay);
- ErrorF("vertStart: 0x%X \n", vertStart);
- ErrorF("vertEnd: 0x%X \n", vertEnd);
- ErrorF("vertTotal: 0x%X \n", vertTotal);
- ErrorF("vertBlankStart: 0x%X \n", vertBlankStart);
- ErrorF("vertBlankEnd: 0x%X \n", vertBlankEnd);
-#endif
-
/*
* compute correct Hsync & Vsync polarity
*/
@@ -492,14 +472,6 @@ static void nv_crtc_calc_state_ext(struct drm_crtc *crtc,
struct drm_display_mod
/* Except for rare conditions I2C is enabled on the primary crtc */
if (nv_crtc->index == 0)
regp->crtc_eng_ctrl |= NV_CRTC_FSEL_I2C;
-#if 0
- /* Set overlay to desired crtc. */
- if (dev->overlayAdaptor) {
- NVPortPrivPtr pPriv = GET_OVERLAY_PRIVATE(dev);
- if (pPriv->overlayCRTC == nv_crtc->index)
- regp->crtc_eng_ctrl |= NV_CRTC_FSEL_OVERLAY;
- }
-#endif
/* ADDRESS_SPACE_PNVM is the same as setting HCUR_ASI */
regp->cursor_cfg = NV_PCRTC_CURSOR_CONFIG_CUR_LINES_64 |
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/4] Add support for i.MX8MM GPUs through Etnaviv
From: Frieder Schrempf This series contains patches to enable GPU support for the i.MX8MM. There is currently no upstream support for the display subsystem of the i.MX8MM, but I have a 5.4-based tree with some ported drivers for LCDIF, DSIM bridge, etc. (see [1]) which I used to test the GPU with glmark2. I'm posting this as an RFC for now, as I'm not feeling confident of all of the changes. Especially patch 1 seems a bit like a hack. Maybe someone can help me understand the underlying problem and/or come up with a better fix. [1] https://git.kontron-electronics.de/linux/linux/-/commits/v5.4-ktn Frieder Schrempf (4): drm/etnaviv: Prevent IRQ triggering at probe time on i.MX8MM drm/etnaviv: Fix error path in etnaviv_gpu_clk_enable() drm/etnaviv: Change order of enabling clocks to fix boot on i.MX8MM arm64: dts: imx8mm: Add GPU nodes for 2D and 3D core using Etnaviv arch/arm64/boot/dts/freescale/imx8mm.dtsi | 36 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 68 ++- 2 files changed, 79 insertions(+), 25 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/format_helper: Dual licence the header in GPL-2 and MIT
Source file was dual licenced but the header was omitted, fix that. Contributors for this file are: Noralf Trønnes Gerd Hoffmann Thomas Gleixner Acked-by: Gerd Hoffmann Acked-by: Noralf Trønnes Signed-off-by: Emmanuel Vadot --- Change in v2: Retain the GPL-2.0-or-later SPDF identifier. include/drm/drm_format_helper.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h index ac220aa1a245..b8ddf473ef77 100644 --- a/include/drm/drm_format_helper.h +++ b/include/drm/drm_format_helper.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* SPDX-License-Identifier: GPL-2.0-or-later or MIT */ /* * Copyright (C) 2016 Noralf Trønnes */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 2/2] drm/format_helper: Dual licence the header in GPL-2 and MIT
Source file was dual licenced but the header was omitted, fix that. Contributors for this file are: Noralf Trønnes Gerd Hoffmann Thomas Gleixner Acked-by: Gerd Hoffmann Acked-by: Noralf Trønnes Signed-off-by: Emmanuel Vadot --- include/drm/drm_format_helper.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h index ac220aa1a245..7c5d4ffb2af2 100644 --- a/include/drm/drm_format_helper.h +++ b/include/drm/drm_format_helper.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ /* * Copyright (C) 2016 Noralf Trønnes */ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] drm/etnaviv: Prevent IRQ triggering at probe time on i.MX8MM
Hi Lucas,
On 30.04.20 16:32, Lucas Stach wrote:
> Hi Frieder,
>
> Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
>> From: Frieder Schrempf
>>
>> On i.MX8MM there is an interrupt getting triggered immediately after
>> requesting the IRQ, which leads to a stall as the handler accesses
>> the GPU registers whithout the clock being enabled.
>>
>> Enabling the clocks briefly seems to clear the IRQ state, so we do
>> this before requesting the IRQ.
>
> This is most likely caused by improper power-up sequencing. Normally
> the GPC will trigger a hardware reset of the modules inside a power
> domain when the domain is powered on. This requires the clocks to be
> running at this point, as those resets are synchronous, so need clock
> pulses to propagate through the hardware.
Ok, I was suspecting something like that and your explanation makes
total sense to me.
>
> From what I see the i.MX8MM is still missing the power domain
> controller integration, but I'm pretty confident that this problem
> should be solved in the power domain code, instead of the GPU driver.
Ok. I was hoping that GPU support could be added without power domain
control, but I now see that this is probably not reasonable at all.
So I will keep on hoping that NXP comes up with an upstreamable solution
for the power domain handling.
Thanks,
Frieder
>
> Regards,
> Lucas
>
>> Signed-off-by: Frieder Schrempf
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 29 -
>> --
>> 1 file changed, 22 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index a31eeff2b297..23877c1f150a 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -1775,13 +1775,6 @@ static int etnaviv_gpu_platform_probe(struct
>> platform_device *pdev)
>> return gpu->irq;
>> }
>>
>> -err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0,
>> - dev_name(gpu->dev), gpu);
>> -if (err) {
>> -dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq,
>> err);
>> -return err;
>> -}
>> -
>> /* Get Clocks: */
>> gpu->clk_reg = devm_clk_get(&pdev->dev, "reg");
>> DBG("clk_reg: %p", gpu->clk_reg);
>> @@ -1805,6 +1798,28 @@ static int etnaviv_gpu_platform_probe(struct
>> platform_device *pdev)
>> gpu->clk_shader = NULL;
>> gpu->base_rate_shader = clk_get_rate(gpu->clk_shader);
>>
>> +/*
>> + * On i.MX8MM there is an interrupt getting triggered
>> immediately
>> + * after requesting the IRQ, which leads to a stall as the
>> handler
>> + * accesses the GPU registers whithout the clock being enabled.
>> + * Enabling the clocks briefly seems to clear the IRQ state, so
>> we do
>> + * this here before requesting the IRQ.
>> + */
>> +err = etnaviv_gpu_clk_enable(gpu);
>> +if (err)
>> +return err;
>> +
>> +err = etnaviv_gpu_clk_disable(gpu);
>> +if (err)
>> +return err;
>> +
>> +err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0,
>> + dev_name(gpu->dev), gpu);
>> +if (err) {
>> +dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq,
>> err);
>> +return err;
>> +}
>> +
>> /* TODO: figure out max mapped size */
>> dev_set_drvdata(dev, gpu);
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/bridge: adv7511: Fix cec clock EPROBE_DEFER handling
If adv7511's devm_clk_get() for the cec clock returns -EPROBE_DEFER, we
end up in an infinite probe loop. This happens:
(1) adv7511's probe is called.
(2) adv7511's probe adds some secondary i2c devices which bind to the
dummy driver and thus call driver_deferred_probe_trigger() and
increment deferred_trigger_count (see driver_bound()).
(3) adv7511's probe returns -EPROBE_DEFER, and since the
deferred_trigger_count has changed during the probe call,
driver_deferred_probe_trigger() is called immediately (see
really_probe()) and adv7511's probe is scheduled.
(4) Goto step 1.
[ 61.972915] really_probe: bus: 'i2c': really_probe: probing driver adv7511
with device 0-0039
[ 61.992734] really_probe: bus: 'i2c': really_probe: probing driver dummy
with device 0-003f
[ 61.993343] driver_bound: driver: 'dummy': driver_bound: bound to device
'0-003f'
[ 61.993626] really_probe: bus: 'i2c': really_probe: bound device 0-003f to
driver dummy
[ 61.995604] really_probe: bus: 'i2c': really_probe: probing driver dummy
with device 0-0038
[ 61.996381] driver_bound: driver: 'dummy': driver_bound: bound to device
'0-0038'
[ 61.996663] really_probe: bus: 'i2c': really_probe: bound device 0-0038 to
driver dummy
[ 61.998651] really_probe: bus: 'i2c': really_probe: probing driver dummy
with device 0-003c
[ 61.999222] driver_bound: driver: 'dummy': driver_bound: bound to device
'0-003c'
[ 61.999496] really_probe: bus: 'i2c': really_probe: bound device 0-003c to
driver dummy
[ 62.010050] really_probe: i2c 0-0039: Driver adv7511 requests probe deferral
[ 62.011380] really_probe: bus: 'platform': really_probe: probing driver
pwm-clock with device clock-cec
[ 62.012812] really_probe: platform clock-cec: Driver pwm-clock requests
probe deferral
[ 62.024679] really_probe: bus: 'i2c': really_probe: probing driver adv7511
with device 0-0039
Fix this by calling devm_clk_get() before registering the secondary
devices.
Signed-off-by: Vincent Whitchurch
---
v2: Add devm_clk_put() in error path.
drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 31
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 11 +--
2 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
index a20a45c0b353..f5e9d0b238d2 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
@@ -286,28 +286,17 @@ static const struct cec_adap_ops adv7511_cec_adap_ops = {
.adap_transmit = adv7511_cec_adap_transmit,
};
-static int adv7511_cec_parse_dt(struct device *dev, struct adv7511 *adv7511)
-{
- adv7511->cec_clk = devm_clk_get(dev, "cec");
- if (IS_ERR(adv7511->cec_clk)) {
- int ret = PTR_ERR(adv7511->cec_clk);
-
- adv7511->cec_clk = NULL;
- return ret;
- }
- clk_prepare_enable(adv7511->cec_clk);
- adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
- return 0;
-}
-
int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
{
unsigned int offset = adv7511->type == ADV7533 ?
ADV7533_REG_CEC_OFFSET : 0;
- int ret = adv7511_cec_parse_dt(dev, adv7511);
+ int ret;
- if (ret)
- goto err_cec_parse_dt;
+ if (!adv7511->cec_clk)
+ goto err_cec_no_clock;
+
+ clk_prepare_enable(adv7511->cec_clk);
+ adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
adv7511->cec_adap = cec_allocate_adapter(&adv7511_cec_adap_ops,
adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
@@ -342,8 +331,12 @@ int adv7511_cec_init(struct device *dev, struct adv7511
*adv7511)
err_cec_alloc:
dev_info(dev, "Initializing CEC failed with error %d, disabling CEC\n",
ret);
-err_cec_parse_dt:
+ clk_disable_unprepare(adv7511->cec_clk);
+ devm_clk_put(dev, adv7511->cec_clk);
+ /* Ensure that adv7511_remove() doesn't attempt to disable it again. */
+ adv7511->cec_clk = NULL;
+err_cec_no_clock:
regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
ADV7511_CEC_CTRL_POWER_DOWN);
- return ret == -EPROBE_DEFER ? ret : 0;
+ return 0;
}
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9e13e466e72c..ebc548e23ece 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1122,6 +1122,15 @@ static int adv7511_probe(struct i2c_client *i2c, const
struct i2c_device_id *id)
if (ret)
return ret;
+ adv7511->cec_clk = devm_clk_get(dev, "cec");
+ if (IS_ERR(adv7511->cec_clk)) {
+ ret = PTR_ERR(adv7511->cec_clk);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+
Re: [PATCH V1 09/10] arch/kmap: Define kmap_atomic_prot() for all arch's
On Thu, Apr 30, 2020 at 01:38:44PM -0700, ira.we...@intel.com wrote:
> -static inline void *kmap_atomic(struct page *page)
> +static inline void *kmap_atomic_prot(struct page *page, pgprot_t prot)
> {
> preempt_disable();
> pagefault_disable();
> if (!PageHighMem(page))
> return page_address(page);
> - return kmap_atomic_high(page);
> + return kmap_atomic_high_prot(page, prot);
> }
> +#define kmap_atomic(page)kmap_atomic_prot(page, kmap_prot)
OK, so it *was* just a bisect hazard - you return to original semantics
wrt preempt_disable()...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 1/2] drm/client: Dual licence the header in GPL-2 and MIT
Source file was dual licenced but the header was omitted, fix that. Contributors for this file are: Daniel Vetter Matt Roper Maxime Ripard Noralf Trønnes Thomas Zimmermann Acked-by: Noralf Trønnes Acked-by: Matt Roper Acked-by: Daniel Vetter Signed-off-by: Emmanuel Vadot --- include/drm/drm_client.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h index 7402f852d3c4..eb259c2547af 100644 --- a/include/drm/drm_client.h +++ b/include/drm/drm_client.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ #ifndef _DRM_CLIENT_H_ #define _DRM_CLIENT_H_ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/client: Dual licence the header in GPL-2 and MIT
Source file was dual licenced but the header was omitted, fix that. Contributors for this file are: Daniel Vetter Matt Roper Maxime Ripard Noralf Trønnes Thomas Zimmermann Acked-by: Noralf Trønnes Acked-by: Matt Roper Acked-by: Daniel Vetter Acked-by: Maxime Ripard Acked-by: Thomas Zimmermann Signed-off-by: Emmanuel Vadot --- include/drm/drm_client.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h index 7402f852d3c4..eb259c2547af 100644 --- a/include/drm/drm_client.h +++ b/include/drm/drm_client.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 */ +/* SPDX-License-Identifier: GPL-2.0 or MIT */ #ifndef _DRM_CLIENT_H_ #define _DRM_CLIENT_H_ -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/4] drm/etnaviv: Fix error path in etnaviv_gpu_clk_enable()
From: Frieder Schrempf
In case enabling of the bus clock fails etnaviv_gpu_clk_enable()
returns without disabling the already enabled reg clock. Fix this.
Fixes: 65f037e8e908 ("drm/etnaviv: add support for slave interface clock")
Signed-off-by: Frieder Schrempf
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 23877c1f150a..7b138d4dd068 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1496,7 +1496,7 @@ static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
if (gpu->clk_bus) {
ret = clk_prepare_enable(gpu->clk_bus);
if (ret)
- return ret;
+ goto disable_clk_reg;
}
if (gpu->clk_core) {
@@ -1519,6 +1519,9 @@ static int etnaviv_gpu_clk_enable(struct etnaviv_gpu *gpu)
disable_clk_bus:
if (gpu->clk_bus)
clk_disable_unprepare(gpu->clk_bus);
+disable_clk_reg:
+ if (gpu->clk_reg)
+ clk_disable_unprepare(gpu->clk_reg);
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v7 4/8] drm: imx: Add i.MX 6 MIPI DSI host platform driver
From: Daniel Vetter Date: Thu, Apr 30, 2020 at 14:58:41 > On Tue, Apr 28, 2020 at 10:08:04PM +0300, Adrian Ratiu wrote: > > Hi Daniel, > > > > On Tue, 28 Apr 2020, Daniel Vetter wrote: > > > On Wed, Apr 22, 2020 at 04:07:27AM +0300, Laurent Pinchart wrote: > > > > Hi Adrian, On Tue, Apr 21, 2020 at 07:16:06PM +0300, Adrian Ratiu > > > > wrote: > This adds support for the Synopsis DesignWare MIPI DSI > > > > v1.01 > host controller which is embedded in i.MX 6 SoCs. Based on > > > > > following patches, but updated/extended to work with existing > > > > > support found in the kernel: - drm: imx: Support Synopsys > > > > > DesignWare MIPI DSI host controller > Signed-off-by: Liu Ying > > > > > Cc: Fabio Estevam > > > > Cc: Enric Balletbo > Serra Reviewed-by: Emil > > > > Velikov > Tested-by: Adrian Pop > > > > > Tested-by: Arnaud Ferraris > > > > > Signed-off-by: Sjoerd Simons > > > > > Signed-off-by: Martyn Welch > > > > > Signed-off-by: Adrian Ratiu > > > > > --- Changes since v6: > - Replaced > > > > custom noop encoder with the simple drm encoder > (Enric) - Added > > > > CONFIG_DRM_IMX6_MIPI_DSI depends on > CONFIG_OF (Enric) - Dropped > > > > imx_mipi_dsi_register() because > now it only creates the dummy > > > > encoder which can easily be > done directly in imx_dsi_bind() > > > > > Changes since v5: > - Reword to remove unrelated device tree patch > > > > mention > (Fabio) - Move pllref_clk enable/disable to bind/unbind > > > > > (Ezequiel) - Fix freescale.com -> nxp.com email addresses > > > > > (Fabio) - Also added myself as module author (Fabio) - Use > > > > > DRM_DEV_* macros for consistency, print more error msg > Changes > > > > since v4: > - Split off driver-specific configuration of phy > > > > timings > due to new upstream API. - Move regmap infrastructure > > > > > logic to separate commit (Ezequiel) - Move dsi v1.01 layout > > > > > addition to a separate commit (Ezequiel) - Minor warnings > and > > > > driver name fixes > Changes since v3: > - Renamed platform driver > > > > to reflect it's i.MX6 > only. (Fabio) > Changes since v2: > - > > > > Fixed commit tags. (Emil) > Changes since v1: > - Moved register > > > > definitions & regmap initialization into > bridge module. Platform > > > > drivers get the regmap via > plat_data after calling the bridge > > > > probe. (Emil) > --- > drivers/gpu/drm/imx/Kconfig| 8 > > > > + > drivers/gpu/drm/imx/Makefile | 1 + > > > > > drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c | 391 > > > > > + 3 files changed, 400 insertions(+) > > > > > create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c > diff > > > > --git a/drivers/gpu/drm/imx/Kconfig > b/drivers/gpu/drm/imx/Kconfig > > > > index > 207bf7409dfba..0dffc72df7922 100644 --- > > > > > a/drivers/gpu/drm/imx/Kconfig +++ > b/drivers/gpu/drm/imx/Kconfig @@ > > > > -39,3 +39,11 @@ config > DRM_IMX_HDMI > depends on DRM_IMX help > > > > Choose this if you want to use > HDMI on i.MX6. > + +config > > > > DRM_IMX6_MIPI_DSI + tristate "Freescale i.MX6 > DRM MIPI DSI" > > > > + select DRM_DW_MIPI_DSI +depends on > DRM_IMX + depends > > > > on OF > > > > + help +Choose this if you want > to use MIPI DSI on i.MX6. > > > > diff > > > > --git > a/drivers/gpu/drm/imx/Makefile > > > > b/drivers/gpu/drm/imx/Makefile > index 21cdcc2faabc8..9a7843c593478 > > > > 100644 --- > a/drivers/gpu/drm/imx/Makefile +++ > > > > > b/drivers/gpu/drm/imx/Makefile @@ -9,3 +9,4 @@ > > > > > obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o > obj-$(CONFIG_DRM_IMX_LDB) > > > > += imx-ldb.o > obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o > > > > > +obj-$(CONFIG_DRM_IMX6_MIPI_DSI) += dw_mipi_dsi-imx6.o diff > --git > > > > a/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c > > > > > b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c new file mode 100644 > > > > > index 0..f8a0a4fe16e21 --- /dev/null +++ > > > > > b/drivers/gpu/drm/imx/dw_mipi_dsi-imx6.c @@ -0,0 +1,391 @@ > +// > > > > SPDX-License-Identifier: GPL-2.0+ +/* + * i.MX6 drm > driver - MIPI > > > > DSI Host Controller + * + * Copyright (C) > 2011-2015 Freescale > > > > Semiconductor, Inc. + * Copyright (C) > 2019-2020 Collabora, Ltd. > > > > + */ + +#include > +#include > > > > +#include > +#include > > > > +#include > > > > > +#include +#include > +#include > > > > +#include > +#include > > > > > +#include +#include > > > > > +#include + +#include "imx-drm.h" > > > > + > +#define DSI_PWR_UP 0x04 +#define > RESET > > > > 0 +#define > > > > POWERUP > BIT(0) + +#define DSI_PHY_IF_CTRL 0x5c > > > > > +#define > > > > PHY_IF_CTRL_RESET 0x0 + +#define > DSI_PHY_TST_CTRL0 > > > > 0x64 +#define > > > > PHY_TESTCLK > BIT(1) +#define PHY_UNTESTCLK 0 > > > > +#define > > > > > PHY_TESTCLR BIT(0) +#define > PHY_UNTE
[PATCH 3/4] add drm panel ilitek 9341 driver
From: dillon min Signed-off-by: dillon min --- drivers/gpu/drm/panel/Kconfig| 8 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 555 +++ 3 files changed, 564 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index a1723c1..e42692c 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -95,6 +95,14 @@ config DRM_PANEL_ILITEK_IL9322 Say Y here if you want to enable support for Ilitek IL9322 QVGA (320x240) RGB, YUV and ITU-T BT.656 panels. +config DRM_PANEL_ILITEK_IL9341 + tristate "Ilitek ILI9341 240x320 QVGA panels" + depends on OF && SPI + select REGMAP + help + Say Y here if you want to enable support for Ilitek IL9341 + QVGA (240x320) RGB panels. + config DRM_PANEL_ILITEK_ILI9881C tristate "Ilitek ILI9881C-based panels" depends on OF diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 96a883c..d123543 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o +obj-$(CONFIG_DRM_PANEL_ILITEK_IL9341) += panel-ilitek-ili9341.o obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c new file mode 100644 index 000..dafae89 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c @@ -0,0 +1,555 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Ilitek ILI9341 TFT LCD drm_panel driver. + * + * This panel can be configured to support: + * - 16-bit parallel RGB interface + * + * Copyright (C) 2020 Dillon Min + * Derived from drivers/drm/gpu/panel/panel-ilitek-ili9322.c + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include + +#define DEFAULT_SPI_SPEED 1000 + +#define ILI9341_SLEEP_OUT0x11 /* Sleep out register */ +#define ILI9341_GAMMA0x26 /* Gamma register */ +#define ILI9341_DISPLAY_OFF 0x28 /* Display off register */ +#define ILI9341_DISPLAY_ON 0x29 /* Display on register */ +#define ILI9341_COLUMN_ADDR 0x2A /* Colomn address register */ +#define ILI9341_PAGE_ADDR0x2B /* Page address register */ +#define ILI9341_GRAM 0x2C /* GRAM register */ +#define ILI9341_MAC 0x36 /* Memory Access Control register*/ +#define ILI9341_PIXEL_FORMAT 0x3A /* Pixel Format register */ +#define ILI9341_WDB 0x51 /* Write Brightness Display + register */ +#define ILI9341_WCD 0x53 /* Write Control Display + register*/ +#define ILI9341_RGB_INTERFACE0xB0 /* RGB Interface Signal Control */ +#define ILI9341_FRC 0xB1 /* Frame Rate Control register */ +#define ILI9341_BPC 0xB5 /* Blanking Porch Control + register*/ +#define ILI9341_DFC 0xB6 /* Display Function Control + register*/ +#define ILI9341_POWER1 0xC0 /* Power Control 1 register */ +#define ILI9341_POWER2 0xC1 /* Power Control 2 register */ +#define ILI9341_VCOM10xC5 /* VCOM Control 1 register */ +#define ILI9341_VCOM20xC7 /* VCOM Control 2 register */ +#define ILI9341_POWERA 0xCB /* Power control A register */ +#define ILI9341_POWERB 0xCF /* Power control B register */ +#define ILI9341_PGAMMA 0xE0 /* Positive Gamma Correction + register*/ +#define ILI9341_NGAMMA 0xE1 /* Negative Gamma Correction + register*/ +#define ILI9341_DTCA 0xE8 /* Driver timing control A */ +#define ILI9341_DTCB 0xEA /* Driver timing control B */ +#define ILI9341_POWER_SEQ0xED /* Power on sequence register */ +#define ILI9341_3GAMMA_EN0xF2 /* 3 Gamma enable register */ +#define ILI9341_INTERFACE0xF6 /* Interface control register */ +#define ILI9341_PRC 0xF7
Re: [PATCH 00/17] drm/mgag200: Convert to atomic modesetting
On 4/30/20 3:29 AM, Thomas Zimmermann wrote: Hi John Am 30.04.20 um 02:11 schrieb John Donnelly: On 4/29/20 9:32 AM, Thomas Zimmermann wrote: This patchset converts mgag200 to atomic modesetting. It uses simple KMS helpers and SHMEM. Patches 1 to 4 simplifies the driver before the conversion. For example, the HW cursor is not usable with the way universal planes work. A few data structures can be cleaned up. Patches 5 to 15 untangle the existing modesetting code into smaller functions. Specifically, mode setting and plane updates are being separated from each other. Patch 16 converts mgag200 to simple KMS helpers and enables atomic mode setting. As some HW seems to require a framebuffer offset of 0 within the video memory, it does not work with atomic modesetting. Atomically switching plane framebuffers, requires either source or target buffer to be located at a non-0 offet. To resolve this problem, patch 17 converts mgag200 from VRAM helpers to SHMEM helpers. During plane updates, the content of the SHMEM BO is memcpy'd to VRAM. From my subjective obersation, performance is not nuch different from the original code. The patchset has been tested on MGA G200EH hardware. Thomas Zimmermann (17): drm/mgag200: Remove HW cursor drm/mgag200: Remove unused fields from struct mga_device drm/mgag200: Embed connector instance in struct mga_device drm/mgag200: Use managed mode-config initialization drm/mgag200: Clean up mga_set_start_address() drm/mgag200: Clean up mga_crtc_do_set_base() drm/mgag200: Move mode-setting code into separate helper function drm/mgag200: Split MISC register update into PLL selection, SYNC and I/O drm/mgag200: Update mode registers after plane registers drm/mgag200: Set pitch in a separate helper function drm/mgag200: Set primary plane's format in separate helper function drm/mgag200: Move TAGFIFO reset into separate function drm/mgag200: Move hiprilvl setting into separate functions drm/mgag200: Move register initialization into separate function drm/mgag200: Remove waiting from DPMS code drm/mgag200: Convert to simple KMS helper drm/mgag200: Replace VRAM helpers with SHMEM helpers drivers/gpu/drm/mgag200/Kconfig | 4 +- drivers/gpu/drm/mgag200/Makefile | 2 +- drivers/gpu/drm/mgag200/mgag200_cursor.c | 319 drivers/gpu/drm/mgag200/mgag200_drv.c | 51 +- drivers/gpu/drm/mgag200/mgag200_drv.h | 43 +- drivers/gpu/drm/mgag200/mgag200_main.c | 28 - drivers/gpu/drm/mgag200/mgag200_mode.c | 948 --- drivers/gpu/drm/mgag200/mgag200_reg.h | 5 +- drivers/gpu/drm/mgag200/mgag200_ttm.c | 35 +- 9 files changed, 563 insertions(+), 872 deletions(-) delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c -- 2.26.0 Hi Thomas , I would like to test this on hardware that uses this device integrated into as BMC ( iLo ) that I have ran into problems before. Can you post your staging URL so I can clone it ? Sure, I'll set something up for you. But it could take until next week. I promise not to merge the patches before you had a chance to test them. Best regards Thomas Hi I may try to apply these patches locally .. It won't be until next week though . ( Thank you for CC'ing me. I removed my email from on dlist recently) . -- Thank You, John ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Fix undefined "rd_full" link error
rd_full should be defined outside the CONFIG_DEBUG_FS region, in order
to be able to link the msm driver even when CONFIG_DEBUG_FS is disabled.
Fixes: e515af8d4a6f ("drm/msm: devcoredump should dump MSM_SUBMIT_BO_DUMP
buffers")
Reported-by: Stephen Rothwell
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/msm_rd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c
index 732f65df5c4f..fea30e7aa9e8 100644
--- a/drivers/gpu/drm/msm/msm_rd.c
+++ b/drivers/gpu/drm/msm/msm_rd.c
@@ -29,8 +29,6 @@
* or shader programs (if not emitted inline in cmdstream).
*/
-#ifdef CONFIG_DEBUG_FS
-
#include
#include
#include
@@ -47,6 +45,8 @@ bool rd_full = false;
MODULE_PARM_DESC(rd_full, "If true, $debugfs/.../rd will snapshot all buffer
contents");
module_param_named(rd_full, rd_full, bool, 0600);
+#ifdef CONFIG_DEBUG_FS
+
enum rd_sect_type {
RD_NONE,
RD_TEST, /* ascii text */
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next v2] drm/mcde: dsi: Fix return value check in mcde_dsi_bind()
The of_drm_find_bridge() function returns NULL on error, it doesn't return
error pointers so this check doesn't work.
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Wei Yongjun
---
v1 - > v2: add fixes and fix the subject
---
drivers/gpu/drm/mcde/mcde_dsi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
index 7af5ebb0c436..e705afc08c4e 100644
--- a/drivers/gpu/drm/mcde/mcde_dsi.c
+++ b/drivers/gpu/drm/mcde/mcde_dsi.c
@@ -1073,10 +1073,9 @@ static int mcde_dsi_bind(struct device *dev, struct
device *master,
panel = NULL;
bridge = of_drm_find_bridge(child);
- if (IS_ERR(bridge)) {
- dev_err(dev, "failed to find bridge (%ld)\n",
- PTR_ERR(bridge));
- return PTR_ERR(bridge);
+ if (!bridge) {
+ dev_err(dev, "failed to find bridge\n");
+ return -EINVAL;
}
}
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: drm/amdgpu: Disable [1002:6611] in radeon
The AMD/ATI Oland [1002:6611]'s HDMI output status is not synchronous
as shown on UI after hot re-plug the HDMI cable, if it is radeon in
used. The amdgpu module does not hit this issue.
This patch disables [1002:6611] in radeon and enables it in amdgpu.
Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/1117
Signed-off-by: Jian-Hong Pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
include/drm/drm_pciids.h| 1 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8ea86ffdea0d..1ad6f13a5bc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1017,6 +1017,15 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static struct drm_driver kms_driver;
+static void amdgpu_pci_fixup(struct pci_dev *pdev)
+{
+#ifdef CONFIG_DRM_AMDGPU_SI
+ /* [1002:6611] is disabled in radeon, so enable si_support in amdgpu. */
+ if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x6611)
+ amdgpu_si_support = 1;
+#endif
+}
+
static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1036,6 +1045,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
+ amdgpu_pci_fixup(pdev);
+
#ifdef CONFIG_DRM_AMDGPU_SI
if (!amdgpu_si_support) {
switch (flags & AMD_ASIC_MASK) {
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index b7e899ce44f0..57368a0f5b82 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -171,7 +171,6 @@
{0x1002, 0x6607, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6608, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6610, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
- {0x1002, 0x6611, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6613, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6617, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6620, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Thu, Apr 30, 2020 at 03:54:38PM +0200, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 09:47:46PM +0800, Xin Ji wrote:
> > Hi Daniel,
> >
> > On Thu, Apr 30, 2020 at 03:38:39PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 30, 2020 at 03:37:31PM +0200, Daniel Vetter wrote:
> > > > On Thu, Apr 30, 2020 at 11:36:14AM +0800, Xin Ji wrote:
> > > > > On Tue, Apr 28, 2020 at 12:05:08PM +0200, Daniel Vetter wrote:
> > > > > > On Fri, Apr 24, 2020 at 08:12:04PM +0800, Nicolas Boichat wrote:
> > > > > > > On Fri, Apr 24, 2020 at 2:51 PM Xin Ji
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Apr 23, 2020 at 07:55:15PM +0800, Nicolas Boichat wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > Just commenting on the mode_fixup function that was added in
> > > > > > > > > v7.
> > > > > > > > >
> > > > > > > > [snip]
> > > > > > > > > > + /*
> > > > > > > > > > +* once illegal timing detected, use default HFP,
> > > > > > > > > > HSYNC, HBP
> > > > > > > > > > +*/
> > > > > > > > > > + if (hblanking < HBLANKING_MIN || (hfp < HP_MIN &&
> > > > > > > > > > hbp < HP_MIN)) {
> > > > > > > > >
> > > > > > > > > should this be adj_hblanking/adj_hfp/adj_hbp?
> > > > > > > > NO, need check original HFP and HBP, if they are not legal,
> > > > > > > > driver need
> > > > > > > > set default value to adj_hsync, adj_hfp, adj_hbp.
> > > > > > > > >
> > > > > > > > > > + adj_hsync = SYNC_LEN_DEF;
> > > > > > > > > > + adj_hfp = HFP_HBP_DEF;
> > > > > > > > > > + adj_hbp = HFP_HBP_DEF;
> > > > > > > > > > + vref = adj->clock * 1000 / (adj->htotal *
> > > > > > > > > > adj->vtotal);
> > > > > > > > > > + if (hblanking < HBLANKING_MIN) {
> > > > > > > > > > + delta_adj = HBLANKING_MIN -
> > > > > > > > > > hblanking;
> > > > > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > > > > adj->vtotal;
> > > > > > > > > > + adj->clock +=
> > > > > > > > > > DIV_ROUND_UP(adj_clock, 1000);
> > > > > > > > > > + } else {
> > > > > > > > > > + delta_adj = hblanking -
> > > > > > > > > > HBLANKING_MIN;
> > > > > > > > > > + adj_clock = vref * delta_adj *
> > > > > > > > > > adj->vtotal;
> > > > > > > > > > + adj->clock -=
> > > > > > > > > > DIV_ROUND_UP(adj_clock, 1000);
> > > > > > > > > > + }
> > > > > > > > > > +
> > > > > > > > > > + DRM_WARN("illegal hblanking timing, use
> > > > > > > > > > default.\n");
> > > > > > > > > > + DRM_WARN("hfp(%d),hbp(%d),hsync(%d).\n",
> > > > > > > > > > hfp, hbp, hsync);
> > > > > > > > >
> > > > > > > > > How likely is it that this mode is going to work? Can you
> > > > > > > > > just return
> > > > > > > > > false here to reject the mode?
> > > > > > > > We want to set the default minimal Hblancking value, then it
> > > > > > > > may display,
> > > > > > > > otherwise. If we just return false, there is no display for
> > > > > > > > sure.
> > > > > > >
> > > > > > > Right, understand your argument. I'm pondering if it's not just
> > > > > > > better
> > > > > > > to reject the mode rather than trying a timing that is definitely
> > > > > > > quite different from what the monitor was asking for. No super
> > > > > > > strong
> > > > > > > opinion, I'll let other people on the list weigh in.
> > > > > >
> > > > > > Yeah mode_fixup is supposed to be used to adjust the mode in
> > > > > > intermediate
> > > > > > stages (e.g. if you go from progressive to interlaced only at the
> > > > > > end of
> > > > > > your pipeline or something like that). It's not meant for adjusting
> > > > > > the
> > > > > > mode yout actually put out through a hdmi or dp connector. For fixed
> > > > > > panels adjusting modes to fit the panel is also fairly common, but
> > > > > > not for
> > > > > > external outputs.
> > > > > >
> > > > > > Since this is a DP bridge I'd say no adjusting, just reject what
> > > > > > doesn't
> > > > > > fit.
> > > > > We have found some panel which HBP less than 8, if we reject to adjust
> > > > > video timing, then there is no display. The customer does not accept
> > > > > it,
> > > > > they push us to fix it, the only resolve way is to adjust timing.
> > > >
> > > > Are we talking about external DP screen here, or some built-in panel?
> > > > For
> > > > the later case we do a lot of mode adjusting in many drivers ...
> > > >
> > > > I haven't checked, by if our connector type is eDP then this should be
> > > > all
> > > > fine.
> > >
> > > Ok I read the patch now, you seem to support both. Would it work if we
> > > make this adjustement conditional on it being an internal panel only? I
> > > think that would be perfect.
> > > -Daniel
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > Based on comments of V8, only keeped e
[PULL] drm-misc-fixes
Hi! Here's this week drm-misc-fixes PR Thanks! Maxime drm-misc-fixes-2020-04-30: A few resources-related fixes for qxl, some doc build warnings and ioctl fixes for dma-buf, an off-by-one fix in edid, and a return code fix in DP-MST The following changes since commit 9da67433f64eb89e5a7b47977507806c6ea026e7: drm/tidss: fix crash related to accessing freed memory (2020-04-20 10:07:35 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-04-30 for you to fetch changes up to 6f49c2515e2258f08f2b905c9772dbf729610415: dma-buf: fix documentation build warnings (2020-04-30 19:47:39 +0530) A few resources-related fixes for qxl, some doc build warnings and ioctl fixes for dma-buf, an off-by-one fix in edid, and a return code fix in DP-MST Daniel Vetter (1): dma-buf: Fix SET_NAME ioctl uapi Gurchetan Singh (1): drm/virtio: only destroy created contexts Lyude Paul (1): drm/dp_mst: Fix drm_dp_send_dpcd_write() return code Randy Dunlap (1): dma-buf: fix documentation build warnings Vasily Averin (4): drm/qxl: qxl_release leak in qxl_draw_dirty_fb() drm/qxl: qxl_release leak in qxl_hw_surface_alloc() drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper() drm/qxl: qxl_release use after free Ville Syrjälä (1): drm/edid: Fix off-by-one in DispID DTD pixel clock drivers/dma-buf/dma-buf.c | 7 --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 ++-- drivers/gpu/drm/drm_edid.c| 2 +- drivers/gpu/drm/qxl/qxl_cmd.c | 10 +- drivers/gpu/drm/qxl/qxl_display.c | 6 +++--- drivers/gpu/drm/qxl/qxl_draw.c| 7 --- drivers/gpu/drm/qxl/qxl_image.c | 3 ++- drivers/gpu/drm/qxl/qxl_ioctl.c | 5 + drivers/gpu/drm/virtio/virtgpu_kms.c | 17 ++--- include/linux/dma-buf.h | 3 +-- include/uapi/linux/dma-buf.h | 6 ++ 11 files changed, 39 insertions(+), 35 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341
Hi Alexandre,
Alexandre Torgue 于2020年4月30日周四 下午5:57写道：
> Hi
>
> On 4/30/20 11:43 AM, dillon.min...@gmail.com wrote:
> > From: dillon min
> >
> > Signed-off-by: dillon min
>
> Commit title should be ARM: dts: stm32: bla bla on stm32f429 and please
> a commit message.
>
>
*okay, thanks for your quicky response, this is my first kernel pull
request, i will resubmit all patchsets following the history submits style
who was did.*
> > ---
> > .../bindings/display/panel/ilitek,ili9341.txt | 42 +++
> > arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 79
> +++
> > arch/arm/boot/dts/stm32f429-disco.dts | 88
> ++
> > arch/arm/boot/dts/stm32f429.dtsi | 12 +++
> > 4 files changed, 221 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> >
> > diff --git
> a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
>
> This binding description should be in a separate patch and you have to
> write in YAML format.
>
> *okay, will do it later. *
>
> > new file mode 100644
> > index 000..f5a4e55
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
> > @@ -0,0 +1,42 @@
> > +Ilitek ILI9341 TFT panel driver with SPI control bus
> > +
> > +This is a driver for 240x320 TFT panels, accepting a rgb input
> > +streams that get adapted and scaled to the panel.
> > +
> > +Required properties:
> > + - compatible: "stm32f429-disco,ltdc-panel", "ilitek,ili9341"
> > +(full system-specific compatible is always required to look up
> configuration)
> > + - reg: address of the panel on the SPI bus
> > +
> > +Optional properties:
> > + - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
> > + - dc-gpios: a GPIO spec for the dc pin, see gpio/gpio.txt
> > +
> > + The following optional properties only apply to RGB input mode:
> > +
> > + - pixelclk-active: see display/panel/display-timing.txt
> > + - de-active: see display/panel/display-timing.txt
> > + - hsync-active: see display/panel/display-timing.txt
> > + - vsync-active: see display/panel/display-timing.txt
> > +
> > +The panel must obey the rules for a SPI slave device as specified in
> > +spi/spi-bus.txt
> > +
> > +The device node can contain one 'port' child node with one child
> > +'endpoint' node, according to the bindings defined in
> > +media/video-interfaces.txt. This node should describe panel's video bus.
> > +
> > +Example:
> > +
> > +panel: display@0 {
> > + compatible = "stm32f429-disco,ltdc-panel", "ilitek,ili9341";
> > + reg = <0>;
> > + spi-3wire;
> > + spi-max-frequency = <1000>;
> > + dc-gpios = <&gpiod 13 0>;
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&display_out>;
> > + };
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> > index 392fa14..45b68f4 100644
> > --- a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> > +++ b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
> > @@ -316,6 +316,85 @@
> > };
> > };
> >
> > + ltdc_pins_f429_disco: ltdc-1 {
> > + pins {
> > + pinmux = AF14)>,
> > + /* LCD_HSYNC */
> > + AF14)>,
> > + /* LCD_VSYNC */
> > + AF14)>,
> > + /* LCD_CLK */
> > + AF14)>,
> > + /* LCD_R2 */
> > + AF9)>,
> > + /* LCD_R3 */
> > + AF14)>,
> > + /* LCD_R4 */
> > + AF14)>,
> > + /* LCD_R5 */
> > + AF9)>,
> > + /* LCD_R6*/
> > + AF14)>,
> > + /* LCD_R7 */
> > + AF14)>,
> > + /* LCD_G2 */
> > + AF9)>,
> > + /* LCD_G3 */
> > + AF14)>,
> > + /* LCD_G4 */
> > + AF14)>,
> > +
Re: [PATCH V1 05/10] arch/kmap_atomic: Consolidate duplicate code
On Thu, Apr 30, 2020 at 01:38:40PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > Every arch has the same code to ensure atomic operations and a check for > !HIGHMEM page. > > Remove the duplicate code by defining a core kmap_atomic() which only > calls the arch specific kmap_atomic_high() when the page is high memory. Err AFAICS, you've just silently changed the semantics for kmap_atomic_prot() here. And while most of the callers are converted, drivers/gpu/drm/ttm/ttm_bo_util.c one is not, so at the very least it's a bisect hazard... And I would argue that having kmap_atomic() differ from kmap_atomic_prot() wrt disabling preempt is asking for trouble. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] drm/etnaviv: Prevent IRQ triggering at probe time on i.MX8MM
On 4/30/20 3:46 PM, Schrempf Frieder wrote:
+ /*
+* On i.MX8MM there is an interrupt getting triggered immediately
+* after requesting the IRQ, which leads to a stall as the handler
+* accesses the GPU registers whithout the clock being enabled.
+* Enabling the clocks briefly seems to clear the IRQ state, so we do
+* this here before requesting the IRQ.
+*/
+ err = etnaviv_gpu_clk_enable(gpu);
+ if (err)
+ return err;
+
+ err = etnaviv_gpu_clk_disable(gpu);
+ if (err)
+ return err;
+
+ err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0,
+ dev_name(gpu->dev), gpu);
+ if (err) {
+ dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq, err);
+ return err;
+ }
Shouldn't you disable the clk after devm_request_irq is called?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] add drm panel driver for stm32f429-dicovery board the change details:
From: dillon min
1) add support drm ili9341 panel driver connect to ltdc
2) add i2c3/spi5 ltdc pins dts configuration for gyro/stmpe
3) add SPI_SIMPLEX_RX/SPI_3WIRE_RX in spi-stm32f4.c
for SPI_SIMPLEX_RX , as we running kernel in sdram, so
that the performance is not as good as internal flash,
need add send dummy data out while in rx,
otherwise will get many overrun errors.
4) fix hang bugs durning ltdc driver load , in clk-stm32f4.c
store clk_hw to the wrong offset PLL_VCO_SAI, PLL_VCO_I2S
5) add CLK_IGNORE_UNUSED for ltdc, otherwise system will close
ltdc clk
===
Signed-off-by: dillon min
---
.../bindings/display/panel/ilitek,ili9341.txt | 43 ++
arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 79 +++
arch/arm/boot/dts/stm32f429-disco.dts | 88
arch/arm/boot/dts/stm32f429.dtsi | 12 +
drivers/clk/clk-stm32f4.c | 7 +-
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 561 +
drivers/spi/spi-stm32.c| 26 +-
9 files changed, 818 insertions(+), 7 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
new file mode 100644
index 000..a03825f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
@@ -0,0 +1,43 @@
+Ilitek ILI9341 TFT panel driver with SPI control bus
+
+This is a driver for 320x240 TFT panels, accepting a rgb input
+streams that get adapted and scaled to the panel.
+VCOMH outputs.
+
+Required properties:
+ - compatible: "stm32f429-disco,ltdc-panel", "ilitek,ili9341"
+(full system-specific compatible is always required to look up
configuration)
+ - reg: address of the panel on the SPI bus
+
+Optional properties:
+ - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
+ - dc-gpios: a GPIO spec for the dc pin, see gpio/gpio.txt
+
+ The following optional properties only apply to RGB input mode:
+
+ - pixelclk-active: see display/panel/display-timing.txt
+ - de-active: see display/panel/display-timing.txt
+ - hsync-active: see display/panel/display-timing.txt
+ - vsync-active: see display/panel/display-timing.txt
+
+The panel must obey the rules for a SPI slave device as specified in
+spi/spi-bus.txt
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+
+panel: display@0 {
+ compatible = "stm32f429-disco,ltdc-panel", "ilitek,ili9341";
+ reg = <0>;
+ spi-3wire;
+ spi-max-frequency = <1000>;
+ dc-gpios = <&gpiod 13 0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
index 392fa14..45b68f4 100644
--- a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
@@ -316,6 +316,85 @@
};
};
+ ltdc_pins_f429_disco: ltdc-1 {
+ pins {
+ pinmux = ,
+ /* LCD_HSYNC */
+,
+/* LCD_VSYNC */
+,
+/* LCD_CLK */
+,
+/* LCD_R2 */
+,
+/* LCD_R3 */
+,
+/* LCD_R4 */
+,
+/* LCD_R5 */
+,
+/* LCD_R6*/
+,
+/* LCD_R7 */
+,
+/* LCD_G2 */
+,
+/* LCD_G3 */
+,
+/* LCD_G4 */
+
[PATCH -next] drm/udl: Make udl_handle_damage static
Fix the following sparse warning:
drivers/gpu/drm/udl/udl_modeset.c:269:5: warning: symbol 'udl_handle_damage'
was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/gpu/drm/udl/udl_modeset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 99518a8..fef43f4 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -266,8 +266,8 @@ static int udl_aligned_damage_clip(struct drm_rect *clip,
int x, int y,
return 0;
}
-int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
- int width, int height)
+static int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
+int width, int height)
{
struct drm_device *dev = fb->dev;
struct dma_buf_attachment *import_attach = fb->obj[0]->import_attach;
--
2.6.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: adv7511: Fix cec clock EPROBE_DEFER handling
On Mon, Apr 06, 2020 at 02:58:17AM +0200, Laurent Pinchart wrote:
> On Tue, Mar 31, 2020 at 04:16:29PM +0200, Vincent Whitchurch wrote:
> > int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
> > {
> > unsigned int offset = adv7511->type == ADV7533 ?
> > ADV7533_REG_CEC_OFFSET : 0;
> > - int ret = adv7511_cec_parse_dt(dev, adv7511);
> > + int ret;
> >
> > - if (ret)
> > - goto err_cec_parse_dt;
> > + if (!adv7511->cec_clk)
> > + goto err_cec_no_clock;
> > +
> > + clk_prepare_enable(adv7511->cec_clk);
> > + adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
> >
> > adv7511->cec_adap = cec_allocate_adapter(&adv7511_cec_adap_ops,
> > adv7511, dev_name(dev), CEC_CAP_DEFAULTS, ADV7511_MAX_ADDRS);
> > @@ -342,8 +331,11 @@ int adv7511_cec_init(struct device *dev, struct
> > adv7511 *adv7511)
> > err_cec_alloc:
> > dev_info(dev, "Initializing CEC failed with error %d, disabling CEC\n",
> > ret);
> > -err_cec_parse_dt:
> > + clk_disable_unprepare(adv7511->cec_clk);
> > + /* Ensure that adv7511_remove() doesn't attempt to disable it again. */
>
> Would it make sense to call devm_clk_put() here to already release the
> clock ?
I've just sent out a v2 with this added. Thank you for the review!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: check to see if SIMD registers are available before using SIMD
Sometimes it's not okay to use SIMD registers, the conditions for which
have changed subtly from kernel release to kernel release. Usually the
pattern is to check for may_use_simd() and then fallback to using
something slower in the unlikely case SIMD registers aren't available.
So, this patch fixes up i915's accelerated memcpy routines to fallback
to boring memcpy if may_use_simd() is false.
Cc: sta...@vger.kernel.org
Signed-off-by: Jason A. Donenfeld
---
drivers/gpu/drm/i915/i915_memcpy.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
b/drivers/gpu/drm/i915/i915_memcpy.c
index fdd550405fd3..7c0e022586bc 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include "i915_memcpy.h"
@@ -38,6 +39,12 @@ static DEFINE_STATIC_KEY_FALSE(has_movntdqa);
#ifdef CONFIG_AS_MOVNTDQA
static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len)
{
+ if (unlikely(!may_use_simd())) {
+ memcpy(dst, src, len);
+ return;
+ }
+
+
kernel_fpu_begin();
while (len >= 4) {
@@ -67,6 +74,11 @@ static void __memcpy_ntdqa(void *dst, const void *src,
unsigned long len)
static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len)
{
+ if (unlikely(!may_use_simd())) {
+ memcpy(dst, src, len);
+ return;
+ }
+
kernel_fpu_begin();
while (len >= 4) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Fix a NULL vs IS_ERR() check in vbox_hw_init()
> The devm_gen_pool_create() function returns ERR_PTR() on error, it > doesn't return NULL so this check doesn't work. How do you think about a wording variant like the following? Change description: A null pointer check was performed after a call of the function “devm_gen_pool_create” despite of the detail that failures are indicated by error pointers instead. Thus adjust a check for the failure predicate and return the corresponding error code. Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/mcde: dsi: Fix return value check in mcde_dsi_bind()
> The of_drm_find_bridge() function returns NULL on error, it doesn't return > error pointers so this check doesn't work. How do you think about a wording variant like the following? Change description: An error pointer check was performed after a call of the function “of_drm_find_bridge” despite of the detail that failures are indicated for the bridge search by null pointers instead. Thus adjust a check for the failure predicate and the corresponding exception handling. Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v9 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI to DisplayPort 1.3 4K.
You can add support to your board with binding.
Example:
anx7625_bridge: encoder@58 {
compatible = "analogix,anx7625";
reg = <0x58>;
status = "okay";
enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
mipi2dp_bridge_in: port@0 {
reg = <0>;
anx7625_in: endpoint {
remote-endpoint = <&mipi_dsi>;
};
};
mipi2dp_bridge_out: port@1 {
reg = <1>;
anx7625_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};
Signed-off-by: Xin Ji
---
.../bindings/display/bridge/analogix,anx7625.yaml | 97 ++
1 file changed, 97 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
new file mode 100644
index 000..c2c50b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+ - Xin Ji
+
+description: |
+ The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+ designed for portable devices.
+
+properties:
+ "#address-cells": true
+ "#size-cells": true
+
+ compatible:
+items:
+ - const: analogix,anx7625
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: used for interrupt pin B8.
+maxItems: 1
+
+ enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+ reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description:
+ Video port for MIPI DSI input.
+
+ port@1:
+type: object
+description:
+ Video port for panel or connector.
+
+required:
+- port@0
+- port@1
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+anx7625_bridge: encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi2dp_bridge_in: port@0 {
+reg = <0>;
+anx7625_in: endpoint {
+remote-endpoint = <&mipi_dsi>;
+};
+};
+
+mipi2dp_bridge_out: port@1 {
+reg = <1>;
+anx7625_out: endpoint {
+remote-endpoint = <&panel_in>;
+};
+};
+};
+};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/4] drm/etnaviv: Change order of enabling clocks to fix boot on i.MX8MM
On 30.04.20 16:35, Lucas Stach wrote:
> Am Donnerstag, den 30.04.2020, 12:46 + schrieb Schrempf Frieder:
>> From: Frieder Schrempf
>>
>> On some i.MX8MM devices the boot hangs when enabling the GPU clocks.
>> Changing the order of clock initalization to
>>
>> core -> shader -> bus -> reg
>>
>> fixes the issue. This is the same order used in the imx platform code
>> of the downstream GPU driver in the NXP kernel [1]. For the sake of
>> consistency we also adjust the order of disabling the clocks to the
>> reverse.
>>
>> [1]
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Flinux-imx%2Ftree%2Fdrivers%2Fmxc%2Fgpu-viv%2Fhal%2Fos%2Flinux%2Fkernel%2Fplatform%2Ffreescale%2Fgc_hal_kernel_platform_imx.c%3Fh%3Dimx_5.4.3_2.0.0%23n1538&data=02%7C01%7Cfrieder.schrempf%40kontron.de%7Cdae15f14ed4a4999065508d7ed13ae87%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637238541095594019&sdata=%2BImteXNH%2FqJDionnJVHtjVnXJk%2BG%2BVlgvBdRGfnlQro%3D&reserved=0
>
> I don't see why the order of the clocks is important. Is this really a
> GPU issue? As in: does a GPU access hang when enabling the clocks in
> the wrong order? Or is this a clock driver issue with a clock access
> hanging due to an upstream clock still being disabled?
Actually you might be right with this being a clock driver issue. The
hanging happens while enabling the clocks (unrelated to any GPU register
access). The strange thing is that most of the devices we have don't
care and work as is and some devices reliably fail each time when
enabling the clocks in the "wrong" order.
So I guess this could indeed be some clock being enabled with an
upstream PLL not having locked yet or something.
>
> Regards,
> Lucas
>
>> Signed-off-by: Frieder Schrempf
>> ---
>> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 42 +--
>> 1 file changed, 21 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> index 7b138d4dd068..424b2e5951f0 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>> @@ -1487,55 +1487,55 @@ static int etnaviv_gpu_clk_enable(struct etnaviv_gpu
>> *gpu)
>> {
>> int ret;
>>
>> -if (gpu->clk_reg) {
>> -ret = clk_prepare_enable(gpu->clk_reg);
>> +if (gpu->clk_core) {
>> +ret = clk_prepare_enable(gpu->clk_core);
>> if (ret)
>> return ret;
>> }
>>
>> -if (gpu->clk_bus) {
>> -ret = clk_prepare_enable(gpu->clk_bus);
>> +if (gpu->clk_shader) {
>> +ret = clk_prepare_enable(gpu->clk_shader);
>> if (ret)
>> -goto disable_clk_reg;
>> +goto disable_clk_core;
>> }
>>
>> -if (gpu->clk_core) {
>> -ret = clk_prepare_enable(gpu->clk_core);
>> +if (gpu->clk_bus) {
>> +ret = clk_prepare_enable(gpu->clk_bus);
>> if (ret)
>> -goto disable_clk_bus;
>> +goto disable_clk_shader;
>> }
>>
>> -if (gpu->clk_shader) {
>> -ret = clk_prepare_enable(gpu->clk_shader);
>> +if (gpu->clk_reg) {
>> +ret = clk_prepare_enable(gpu->clk_reg);
>> if (ret)
>> -goto disable_clk_core;
>> +goto disable_clk_bus;
>> }
>>
>> return 0;
>>
>> -disable_clk_core:
>> -if (gpu->clk_core)
>> -clk_disable_unprepare(gpu->clk_core);
>> disable_clk_bus:
>> if (gpu->clk_bus)
>> clk_disable_unprepare(gpu->clk_bus);
>> -disable_clk_reg:
>> -if (gpu->clk_reg)
>> -clk_disable_unprepare(gpu->clk_reg);
>> +disable_clk_shader:
>> +if (gpu->clk_shader)
>> +clk_disable_unprepare(gpu->clk_shader);
>> +disable_clk_core:
>> +if (gpu->clk_core)
>> +clk_disable_unprepare(gpu->clk_core);
>>
>> return ret;
>> }
>>
>> static int etnaviv_gpu_clk_disable(struct etnaviv_gpu *gpu)
>> {
>> +if (gpu->clk_reg)
>> +clk_disable_unprepare(gpu->clk_reg);
>> +if (gpu->clk_bus)
>> +clk_disable_unprepare(gpu->clk_bus);
>> if (gpu->clk_shader)
>> clk_disable_unprepare(gpu->clk_shader);
>> if (gpu->clk_core)
>> clk_disable_unprepare(gpu->clk_core);
>> -if (gpu->clk_bus)
>> -clk_disable_unprepare(gpu->clk_bus);
>> -if (gpu->clk_reg)
>> -clk_disable_unprepare(gpu->clk_reg);
>>
>> return 0;
>> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] add drm panel driver for stm32f429-dicovery board the change details:
Hi,
You have first to split this patch in several patches and add relevant
people in TO&CC (using get_maintainer script) for each patch. Quickly,
you should at least have 4 patches (DT, clock driver, spi driver and drm
). Then review will be more efficient.
regards
Alexandre
On 4/30/20 10:07 AM, dillon.min...@gmail.com wrote:
From: dillon min
1) add support drm ili9341 panel driver connect to ltdc
2) add i2c3/spi5 ltdc pins dts configuration for gyro/stmpe
3) add SPI_SIMPLEX_RX/SPI_3WIRE_RX in spi-stm32f4.c
for SPI_SIMPLEX_RX , as we running kernel in sdram, so
that the performance is not as good as internal flash,
need add send dummy data out while in rx,
otherwise will get many overrun errors.
4) fix hang bugs durning ltdc driver load , in clk-stm32f4.c
store clk_hw to the wrong offset PLL_VCO_SAI, PLL_VCO_I2S
5) add CLK_IGNORE_UNUSED for ltdc, otherwise system will close
ltdc clk
===
Signed-off-by: dillon min
---
.../bindings/display/panel/ilitek,ili9341.txt | 43 ++
arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 79 +++
arch/arm/boot/dts/stm32f429-disco.dts | 88
arch/arm/boot/dts/stm32f429.dtsi | 12 +
drivers/clk/clk-stm32f4.c | 7 +-
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 561 +
drivers/spi/spi-stm32.c| 26 +-
9 files changed, 818 insertions(+), 7 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
new file mode 100644
index 000..a03825f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
@@ -0,0 +1,43 @@
+Ilitek ILI9341 TFT panel driver with SPI control bus
+
+This is a driver for 320x240 TFT panels, accepting a rgb input
+streams that get adapted and scaled to the panel.
+VCOMH outputs.
+
+Required properties:
+ - compatible: "stm32f429-disco,ltdc-panel", "ilitek,ili9341"
+(full system-specific compatible is always required to look up
configuration)
+ - reg: address of the panel on the SPI bus
+
+Optional properties:
+ - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
+ - dc-gpios: a GPIO spec for the dc pin, see gpio/gpio.txt
+
+ The following optional properties only apply to RGB input mode:
+
+ - pixelclk-active: see display/panel/display-timing.txt
+ - de-active: see display/panel/display-timing.txt
+ - hsync-active: see display/panel/display-timing.txt
+ - vsync-active: see display/panel/display-timing.txt
+
+The panel must obey the rules for a SPI slave device as specified in
+spi/spi-bus.txt
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+
+panel: display@0 {
+ compatible = "stm32f429-disco,ltdc-panel", "ilitek,ili9341";
+ reg = <0>;
+ spi-3wire;
+ spi-max-frequency = <1000>;
+ dc-gpios = <&gpiod 13 0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
index 392fa14..45b68f4 100644
--- a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
@@ -316,6 +316,85 @@
};
};
+ ltdc_pins_f429_disco: ltdc-1 {
+ pins {
+ pinmux = ,
+ /* LCD_HSYNC */
+,
+/* LCD_VSYNC */
+,
+/* LCD_CLK */
+,
+/* LCD_R2 */
+,
+/* LCD_R3 */
+,
+/* LCD_R4 */
+,
+/* LCD_R5 */
+,
+/* LCD_R6*/
+,
+/* LCD_R7 */
+
Re: [PATCH v8 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
On Thu, Apr 30, 2020 at 09:03:24AM +0200, Sam Ravnborg wrote:
> Hi Xin Ji.
>
> > > > +static void anx7625_power_on_init(struct anx7625_data *ctx)
> > > > +{
> > > > + int retry_count, i;
> > > > + int ret;
> > > > + struct device *dev = &ctx->client->dev;
> > > > +
> > > > + for (retry_count = 0; retry_count < 3; retry_count++) {
> > > > + anx7625_power_on(ctx);
> > > > + anx7625_config(ctx);
> > > > +
> > > > + for (i = 0; i < OCM_LOADING_TIME; i++) {
> > > Code in this for loop is a candidate for a helper function.
> > I didn't find any helper function can be used, so I'll keep it.
> I was not very clear in my way to express this, sorry.
>
> > >
> > > > + /* check interface workable */
> > > > + ret = anx7625_reg_read(ctx,
> > > > ctx->i2c.rx_p0_client,
> > > > + FLASH_LOAD_STA);
> > > > + if (ret < 0) {
> > > > + DRM_ERROR("IO error : access flash
> > > > load.\n");
> > > > + return;
> > > > + }
> > > > + if ((ret & FLASH_LOAD_STA_CHK) ==
> > > > FLASH_LOAD_STA_CHK) {
> > > > + anx7625_disable_pd_protocol(ctx);
> > > > + DRM_DEV_DEBUG_DRIVER(dev,
> > > > +"Firmware ver
> > > > %02x%02x,",
> > > > + anx7625_reg_read(ctx,
> > > > +
> > > > ctx->i2c.rx_p0_client,
> > > > +
> > > > OCM_FW_VERSION),
> > > > + anx7625_reg_read(ctx,
> > > > +
> > > > ctx->i2c.rx_p0_client,
> > > > +
> > > > OCM_FW_REVERSION));
> > > > + DRM_DEV_DEBUG_DRIVER(dev, "Driver
> > > > version %s\n",
> > > > +
> > > > ANX7625_DRV_VERSION);
> > > > +
> > > > + return;
> > > > + }
> > > > + usleep_range(1000, 1100);
> > > > + }
> What I wanted to express is that the for loop is heavily indented.
> So create a small function like:
>
> anx7625_power_on_interface(ctx)
> {
> /* check interface workable */
> ret = anx7625_reg_read(ctx, ctx->i2c.rx_p0_client, FLASH_LOAD_STA);
> if (ret < 0) {
> DRM_ERROR("IO error : access flash load.\n");
> return;
> }
> if ((ret & FLASH_LOAD_STA_CHK) == FLASH_LOAD_STA_CHK) {
> anx7625_disable_pd_protocol(ctx);
> DRM_DEV_DEBUG_DRIVER(dev, "Firmware ver %02x%02x,",
> anx7625_reg_read(ctx, ctx->i2c.rx_p0_client,
> OCM_FW_VERSION),
> anx7625_reg_read(ctx,
>ctx->i2c.rx_p0_client,
> OCM_FW_REVERSION));
> DRM_DEV_DEBUG_DRIVER(dev, "Driver version %s\n",
>ANX7625_DRV_VERSION);
> retunrn 1;
> }
> return 0;
> }
>
> and then
>
> for (i = 0; i < OCM_LOADING_TIME; i++) {
> if (anx7625_power_on_interface(ctx))
> return;
> else
> usleep_range(1000, 1100);
> }
>
> Or something like that. To make it more readable.
> I think you get the idea now.
OK, got it, thanks.
>
>
> > > > + container_of(work, struct anx7625_data, extcon_wq);
> > > > + int state = extcon_get_state(ctx->extcon, EXTCON_DISP_DP);
> > > > +
> > > > + mutex_lock(&ctx->lock);
> > > > + anx7625_chip_control(ctx, state);
> > > > + mutex_unlock(&ctx->lock);
> > > I tried to follow the locking - but failed.
> > > Could you check that locking seems correct.
> > >
> > > A standard bridge driver do not need locking,
> > > but this is no small bridge driver so I do not imply that
> > > locking is not needed. Only that I would like you
> > > to check it again as I could not follow it.
> > OK, it seems lock is not necessary, I'll remove itA
> It has a worker, so please be careful in you analysis.
OK, I'll double check it.
>
> > >
> > > > +
> > > > + if (pdata->panel_flags == 1)
> > > > + pdata->internal_panel = 1;
> > > > + else if (pdata->panel_flags == 2)
> > > > + pdata->extcon_supported = 1;
> > > > + DRM_DEV_DEBUG_DRIVER(dev, "%s support extcon, %s internal
> > > > panel\n",
> > > > +pdata->extcon_supported ? "" : "not",
> > > > +pdata->internal_panel ? "has" : "no");
> > > > +
> > > The way the internal panel - versus
[PATCH v9 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/Makefile |2 +-
drivers/gpu/drm/bridge/analogix/Kconfig |8 +
drivers/gpu/drm/bridge/analogix/Makefile |1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 1959 +
drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
5 files changed, 2366 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..bcd388a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += analogix/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e930ff9..c772be2 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -2,3 +2,11 @@
config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config DRM_ANALOGIX_ANX7625
+ tristate "Analogix Anx7625 MIPI to DP interface support"
+ depends on DRM
+ depends on OF
+ help
+ ANX7625 is an ultra-low power 4K mobile HD transmitter designed
+ for portable devices. It converts MIPI/DPI to DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
b/drivers/gpu/drm/bridge/analogix/Makefile
index fdbf3fd..b6c4a19 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..eb7162e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,1959 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "anx7625.h"
+
+/*
+ * There is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+ u8 offset;
+ struct device *dev = &client->dev;
+ int ret;
+
+ if (client == ctx->last_client)
+ return 0;
+
+ ctx->last_client = client;
+
+ if (client == ctx->i2c.tcpc_client)
+ offset = RSVD_00_ADDR;
+ else if (client == ctx->i2c.tx_p0_client)
+ offset = RSVD_D1_ADDR;
+ else if (client == ctx->i2c.tx_p1_client)
+ offset = RSVD_60_ADDR;
+ else if (client == ctx->i2c.rx_p0_client)
+ offset = RSVD_39_ADDR;
+ else if (client == ctx->i2c.rx_p1_client)
+ offset = RSVD_7F_ADDR;
+ else
+ offset = RSVD_00_ADDR;
+
+ ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev,
+ "fail to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+ return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+ struct i2c_client *client, u8 reg_addr)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_read_byte_data(client, reg_addr);
+ if (ret < 0)
+ DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u
Re: [RFC PATCH 1/4] drm/etnaviv: Prevent IRQ triggering at probe time on i.MX8MM
On 30.04.20 16:23, Daniel Baluta wrote:
> On 4/30/20 3:46 PM, Schrempf Frieder wrote:
>> + /*
>> + * On i.MX8MM there is an interrupt getting triggered immediately
>> + * after requesting the IRQ, which leads to a stall as the handler
>> + * accesses the GPU registers whithout the clock being enabled.
>> + * Enabling the clocks briefly seems to clear the IRQ state, so
>> we do
>> + * this here before requesting the IRQ.
>> + */
>> + err = etnaviv_gpu_clk_enable(gpu);
>> + if (err)
>> + return err;
>> +
>> + err = etnaviv_gpu_clk_disable(gpu);
>> + if (err)
>> + return err;
>> +
>> + err = devm_request_irq(&pdev->dev, gpu->irq, irq_handler, 0,
>> + dev_name(gpu->dev), gpu);
>> + if (err) {
>> + dev_err(dev, "failed to request IRQ%u: %d\n", gpu->irq, err);
>> + return err;
>> + }
>
> Shouldn't you disable the clk after devm_request_irq is called?
That's what I first thought, too. But then I found out, that merely
enabling the clocks will clear the sparse interrupt and cause the
handler not to be called during probe anymore.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Msg "PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 [ast] returns -22" after migrating to V5.6.7 kernel from v5.5.10.
Hello Thomas,
Yes, you have my OK on the Reporting/Testing tags.
Thanks, Cary Garrett
On Thu, 2020-04-30 at 10:35 +0200, Thomas Zimmermann wrote:
> Hi Cary
>
> Am 29.04.20 um 20:26 schrieb Cary Garrett:
> > Hello Thomas,
> >
> > Good news! After applying the patch and regenerating the ast kernel module,
> > the system will
> > successfully go into suspend state.
> >
> > Thanks for the fast turnaround. Glad I could help.
>
> Great. Can I add your Reported-by and Tested-by tags to the patch?
>
> Best regards
> Thomas
>
> > Regards, Cary.
> >
> > On Wed, 2020-04-29 at 11:14 +0200, Thomas Zimmermann wrote:
> > > Hi Cary,
> > >
> > > thanks for reporting the bug.
> > >
> > > Am 28.04.20 um 22:32 schrieb Cary Garrett:
> > > > Hello Dave,
> > > >
> > > > Generating & booting v5.5.19 kernel, system will successfully enter
> > > > suspend state.
> > > >
> > > > Generating & booting v5.6.0 kernel, system fails to enter suspend
> > > > state.
> > >
> > > It's related to
> > >
> > > 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> > >
> > > Cary, attached is a patch that fixes the problem on my system. Are you
> > > in a position to build and test your own kernels? If so, could you test
> > > the attached patch and report back? Thanks!
> > >
> > > Best regards
> > > Thomas
> > >
> > > > v5.5.19 "lspci - -s 00:04:00" output:
> > > >
> > > > 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
> > > > Graphics Family (rev 30)
> > > > (prog-if
> > > > 00 [VGA controller])
> > > > DeviceName: Onboard VGA
> > > > Subsystem: Super Micro Computer Inc ASPEED Graphics Family
> > > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > > ParErr- Stepping- SERR-
> > > > FastB2B-
> > > > DisINTx-
> > > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> > > > >TAbort- > > > >SERR-
> > > > > > > Latency: 0
> > > > Interrupt: pin A routed to IRQ 16
> > > > Region 0: Memory at f600 (32-bit, non-prefetchable)
> > > > [size=16M]
> > > > Region 1: Memory at f700 (32-bit, non-prefetchable)
> > > > [size=128K]
> > > > Region 2: I/O ports at d000 [size=128]
> > > > Expansion ROM at 000c [virtual] [disabled] [size=128K]
> > > > Capabilities: [40] Power Management version 3
> > > > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> > > > PME(D0+,D1+,D2+,D3hot+,D3cold+)
> > > > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> > > > Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
> > > > Address: Data:
> > > > Kernel driver in use: ast
> > > > Kernel modules: ast
> > > >
> > > > v5.6.0 "lspci - -s 00:04:00" output:
> > > >
> > > > 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
> > > > Graphics Family (rev 30)
> > > > (prog-if
> > > > 00 [VGA controller])
> > > > DeviceName: Onboard VGA
> > > > Subsystem: Super Micro Computer Inc ASPEED Graphics Family
> > > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > > > ParErr- Stepping- SERR-
> > > > FastB2B-
> > > > DisINTx-
> > > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
> > > > >TAbort- > > > >SERR-
> > > > > > > Latency: 0
> > > > Interrupt: pin A routed to IRQ 16
> > > > Region 0: Memory at f600 (32-bit, non-prefetchable)
> > > > [size=16M]
> > > > Region 1: Memory at f700 (32-bit, non-prefetchable)
> > > > [size=128K]
> > > > Region 2: I/O ports at d000 [size=128]
> > > > Expansion ROM at 000c [virtual] [disabled] [size=128K]
> > > > Capabilities: [40] Power Management version 3
> > > > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> > > > PME(D0+,D1+,D2+,D3hot+,D3cold+)
> > > > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> > > > Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
> > > > Address: Data:
> > > > Kernel driver in use: ast
> > > > Kernel modules: ast
> > > >
> > > >
> > > > v5.5.19 "modinfo ast" output:
> > > >
> > > > filename: /lib/modules/5.5.19/kernel/drivers/gpu/drm/ast/ast.ko.xz
> > > > license:GPL and additional rights
> > > > description:AST
> > > > author: Dave Airlie
> > > > firmware: ast_dp501_fw.bin
> > > > srcversion: ABBD643B3936ECA879F0CE8
> > > > alias: pci:v1A03d2010sv*sd*bc03sc*i*
> > > > alias: pci:v1A03d2000sv*sd*bc03sc*i*
> > > > depends:drm,drm_kms_helper,drm_vram_helper,i2c-algo-bit
> > > > retpoline: Y
> > > > intree: Y
> > > > name: ast
> > > > vermagic: 5.5.19 SMP preempt mod_unload
> > > > sig_id: PKCS#7
> > > > signer: Build time autogenerated kernel key
> > > > sig_key:
[PATCH 1/4] add dts node for drm panel driver ili9341 add dts i2c3 for stmpe touch add dts spi5 for gyro & ili9341
From: dillon min
Signed-off-by: dillon min
---
.../bindings/display/panel/ilitek,ili9341.txt | 42 +++
arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 79 +++
arch/arm/boot/dts/stm32f429-disco.dts | 88 ++
arch/arm/boot/dts/stm32f429.dtsi | 12 +++
4 files changed, 221 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
new file mode 100644
index 000..f5a4e55
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
@@ -0,0 +1,42 @@
+Ilitek ILI9341 TFT panel driver with SPI control bus
+
+This is a driver for 240x320 TFT panels, accepting a rgb input
+streams that get adapted and scaled to the panel.
+
+Required properties:
+ - compatible: "stm32f429-disco,ltdc-panel", "ilitek,ili9341"
+(full system-specific compatible is always required to look up
configuration)
+ - reg: address of the panel on the SPI bus
+
+Optional properties:
+ - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
+ - dc-gpios: a GPIO spec for the dc pin, see gpio/gpio.txt
+
+ The following optional properties only apply to RGB input mode:
+
+ - pixelclk-active: see display/panel/display-timing.txt
+ - de-active: see display/panel/display-timing.txt
+ - hsync-active: see display/panel/display-timing.txt
+ - vsync-active: see display/panel/display-timing.txt
+
+The panel must obey the rules for a SPI slave device as specified in
+spi/spi-bus.txt
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+
+panel: display@0 {
+ compatible = "stm32f429-disco,ltdc-panel", "ilitek,ili9341";
+ reg = <0>;
+ spi-3wire;
+ spi-max-frequency = <1000>;
+ dc-gpios = <&gpiod 13 0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
index 392fa14..45b68f4 100644
--- a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
@@ -316,6 +316,85 @@
};
};
+ ltdc_pins_f429_disco: ltdc-1 {
+ pins {
+ pinmux = ,
+ /* LCD_HSYNC */
+,
+/* LCD_VSYNC */
+,
+/* LCD_CLK */
+,
+/* LCD_R2 */
+,
+/* LCD_R3 */
+,
+/* LCD_R4 */
+,
+/* LCD_R5 */
+,
+/* LCD_R6*/
+,
+/* LCD_R7 */
+,
+/* LCD_G2 */
+,
+/* LCD_G3 */
+,
+/* LCD_G4 */
+,
+/* LCD_B2 */
+,
+/* LCD_B3*/
+,
+/* LCD_G5 */
+,
+/* LCD_G6 */
+,
+/* LCD_G7 */
+,
+/* LCD_B4 */
+,
+/* LCD_B5 */
+,
+/* LCD_B6 */
+,
+/
