Re: [PATCH] media: staging: tegra-vde: Fix build error
20.09.2019 22:32, Arnd Bergmann пишет:
> On Thu, Jul 25, 2019 at 2:24 PM Dmitry Osipenko wrote:
>>
>> 25.07.2019 5:41, YueHaibing пишет:
>>> If IOMMU_SUPPORT is not set, and COMPILE_TEST is y,
>>> IOMMU_IOVA may be set to m. So building will fails:
>>>
>>> drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
>>> iommu.c:(.text+0x41): undefined reference to `alloc_iova'
>>> iommu.c:(.text+0x56): undefined reference to `__free_iova'
>>>
>>> Select IOMMU_IOVA while COMPILE_TEST is set to fix this.
>
>>> @@ -3,7 +3,7 @@ config TEGRA_VDE
>>> tristate "NVIDIA Tegra Video Decoder Engine driver"
>>> depends on ARCH_TEGRA || COMPILE_TEST
>>> select DMA_SHARED_BUFFER
>>> - select IOMMU_IOVA if IOMMU_SUPPORT
>>> + select IOMMU_IOVA if (IOMMU_SUPPORT || COMPILE_TEST)
>>> select SRAM
>>> help
>>> Say Y here to enable support for the NVIDIA Tegra video decoder
>>>
>>
>> This results in missing the case of compile-testing !IOMMU_IOVA for the
>> driver, but probably that's not a big deal.
>>
>> Acked-by: Dmitry Osipenko
>
> I don't know what happened here, but the patch from YueHaibing caused this
> error for me, which is very much like the problem it was meant to fix:
>
> drivers/gpu/host1x/dev.o: In function `host1x_probe':
> dev.c:(.text+0x1734): undefined reference to `put_iova_domain'
> dev.c:(.text+0x1744): undefined reference to `iova_cache_put'
> drivers/gpu/host1x/dev.o: In function `host1x_remove':
> dev.c:(.text+0x1894): undefined reference to `put_iova_domain'
> dev.c:(.text+0x1898): undefined reference to `iova_cache_put'
> drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
> cdma.c:(.text+0x5d0): undefined reference to `alloc_iova'
> cdma.c:(.text+0x61c): undefined reference to `__free_iova'
> drivers/gpu/host1x/cdma.o: In function `host1x_cdma_deinit':
> cdma.c:(.text+0x6c8): undefined reference to `free_iova'
> drivers/gpu/host1x/job.o: In function `host1x_job_pin':
> job.c:(.text+0x514): undefined reference to `alloc_iova'
> job.c:(.text+0x528): undefined reference to `__free_iova'
> drivers/gpu/host1x/job.o: In function `host1x_job_unpin':
> job.c:(.text+0x5bc): undefined reference to `free_iova'
>
> After reverthing commit 6b2265975239 ("media: staging:
> tegra-vde: Fix build error"), I can no longer reproduce the
> issue.
There is a follow up here: https://patchwork.ozlabs.org/patch/1153176/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: tegra-vde: Fix build error
On Thu, Jul 25, 2019 at 2:24 PM Dmitry Osipenko wrote:
>
> 25.07.2019 5:41, YueHaibing пишет:
> > If IOMMU_SUPPORT is not set, and COMPILE_TEST is y,
> > IOMMU_IOVA may be set to m. So building will fails:
> >
> > drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
> > iommu.c:(.text+0x41): undefined reference to `alloc_iova'
> > iommu.c:(.text+0x56): undefined reference to `__free_iova'
> >
> > Select IOMMU_IOVA while COMPILE_TEST is set to fix this.
> > @@ -3,7 +3,7 @@ config TEGRA_VDE
> > tristate "NVIDIA Tegra Video Decoder Engine driver"
> > depends on ARCH_TEGRA || COMPILE_TEST
> > select DMA_SHARED_BUFFER
> > - select IOMMU_IOVA if IOMMU_SUPPORT
> > + select IOMMU_IOVA if (IOMMU_SUPPORT || COMPILE_TEST)
> > select SRAM
> > help
> > Say Y here to enable support for the NVIDIA Tegra video decoder
> >
>
> This results in missing the case of compile-testing !IOMMU_IOVA for the
> driver, but probably that's not a big deal.
>
> Acked-by: Dmitry Osipenko
I don't know what happened here, but the patch from YueHaibing caused this
error for me, which is very much like the problem it was meant to fix:
drivers/gpu/host1x/dev.o: In function `host1x_probe':
dev.c:(.text+0x1734): undefined reference to `put_iova_domain'
dev.c:(.text+0x1744): undefined reference to `iova_cache_put'
drivers/gpu/host1x/dev.o: In function `host1x_remove':
dev.c:(.text+0x1894): undefined reference to `put_iova_domain'
dev.c:(.text+0x1898): undefined reference to `iova_cache_put'
drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
cdma.c:(.text+0x5d0): undefined reference to `alloc_iova'
cdma.c:(.text+0x61c): undefined reference to `__free_iova'
drivers/gpu/host1x/cdma.o: In function `host1x_cdma_deinit':
cdma.c:(.text+0x6c8): undefined reference to `free_iova'
drivers/gpu/host1x/job.o: In function `host1x_job_pin':
job.c:(.text+0x514): undefined reference to `alloc_iova'
job.c:(.text+0x528): undefined reference to `__free_iova'
drivers/gpu/host1x/job.o: In function `host1x_job_unpin':
job.c:(.text+0x5bc): undefined reference to `free_iova'
After reverthing commit 6b2265975239 ("media: staging:
tegra-vde: Fix build error"), I can no longer reproduce the
issue.
Arnd
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HELP REQUESTED from the community] Was: Staging status of speakup
On Fri, Sep 20, 2019 at 8:46 AM Greg Kroah-Hartman wrote: > > On Wed, Sep 18, 2019 at 01:30:33PM -0700, Gregory Nowak wrote: > > > Extra line between each attribute (before the "What:" line) would be > > > nice. > > > > In a previous post above, you wrote: > > On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote: > > > Anyway, please put the Description: lines without a blank after that, > > > with the description text starting on that same line. > > > > I understood that to mean that the description text should start on > > the same line, and the blank lines after the description text should > > be removed. I've put them back in. Someone more familiar with the > > speakup code will have to dig into it to resolve the TODO items I > > suppose. > > No problem, this looks good to me. If someone wants to turn this into a > patch adding it to the drivers/staging/speakup/ directory, I'll be glad > to take it and it will allow others to fill in the TODO entries easier. Thank you. I'll create a patch soon. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: remove unnecessary self-assignment
This is a self-assignment which is redundant. Fix this by removing the
self-assignment.
Addresses-Coverity: ("Self assignment")
Signed-off-by: Connor Kuehl
---
drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
index 086f98d38cba..57ae0e83dd3e 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
@@ -552,7 +552,6 @@ void Hal_ReadAntennaDiversity88E(struct adapter *pAdapter,
u8 *PROMContent, bool
pHalData->AntDivCfg = 1; /* 0xC1[3] is ignored. */
} else {
pHalData->AntDivCfg = 0;
- pHalData->TRxAntDivType = pHalData->TRxAntDivType; /* The
value in the driver setting of device manager. */
}
DBG_88E("EEPROM : AntDivCfg = %x, TRxAntDivType = %x\n",
pHalData->AntDivCfg, pHalData->TRxAntDivType);
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
Hello Xin Ji,
Thank you for the patch.
On Fri, Sep 20, 2019 at 06:05:03AM +, 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.
I assume you meant MIPI DSI ? MIPI has released more standards than DSI,
so it doesn't hurt to specify this explicitly.
According to
https://www.analogix.com/en/system/files/AA-002291-PB-6-ANX7625_ProductBrief_0.pdf,
the ANX7625 supports for MIPI DSI and DPI on the input side.
Furthermore, it seems to output DisplayPort on USB Type-C. Should this
be documented ?
> You can add support to your board with binding.
>
> Example:
> anx_bridge: anx7625@58 {
> compatible = "analogix,anx7625";
> reg = <0x58>;
> low-power-mode = <1>;
> dsi-supported = <1>;
> dsi-channel-id = <1>;
> dsi-lanes-num = <4>;
> internal-pannel-supported = <1>;
> pon-gpios = <&gpio0 45 GPIO_ACTIVE_LOW>;
> reset-gpios = <&gpio0 73 GPIO_ACTIVE_LOW>;
> status = "okay";
> port {
> anx7625_1_in: endpoint {
> remote-endpoint = <&mipi_dsi_bridge_1>;
> };
> };
> };
>
> Signed-off-by: Xin Ji
> ---
> .../bindings/display/bridge/anx7625.yaml | 84
> ++
> 1 file changed, 84 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> new file mode 100644
> index 000..95fe18b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> @@ -0,0 +1,84 @@
> +# 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/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:
> + compatible:
> +items:
> + - const: analogix,anx7625
> +
> + reg:
> +maxItems: 1
> +
> + low-power-gpios:
> +description: Low power mode support feature
> +maxItems: 1
> +
> + hpd-gpios:
> +description: used for HPD interrupt
> +maxItems: 1
> +
> + pon-gpios:
> +description: used for power on chip control
> +maxItems: 1
> +
> + reset-gpios:
> +description: used for reset chip control
> +maxItems: 1
How about mentioning which pin of the ANX7625 each GPIO refers to ? For
the low-power, pon and reset GPIOs I assume they directly control the
chip. We have standard names for some GPIOs, such as reset or enable. Is
there one of the low-power and pon GPIOs that would qualify as an enable
signal ?
What is the HPD GPIO for ? Does the chip output and HPD signal ?
> +
> + extcon-supported:
> +description: external connector interface support flag
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> + internal-pannel-supported:
> +description: indicate does internal pannel exist or not
> +$ref: /schemas/types.yaml#/definitions/uint32
s/pannel/panel/
Are those two properties mutually exclusive ? If so you should combine
them in a single required property with two values. My feeling is that
they should be dropped though, please see below.
> +
> + dsi-supported:
> +description: support MIPI DSI or DPI
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> + dsi-channel-id:
> +description: dsi channel index
> +$ref: /schemas/types.yaml#/definitions/uint32
This does not belong to DT, the virtual channel used by the DSI source
should be queried at runtime by communicating between drivers.
> +
> + dsi-lanes-num:
> +description: dsi lanes used num
> +$ref: /schemas/types.yaml#/definitions/uint32
Please use the standard data-lanes property as defined in
video-interface.txt. It should be specified in the DSI endpoints.
> +
> + port@0:
> +type: object
> +description:
> + A port node pointing to MIPI DSI host port node.
You need at least 3 ports:
- a DPI input port
- a DSI input port
- an output port
The dsi-supported property should be dropped, detecting the type of
input should be done based on which of the DPI or DSI input port is
connected.
Assuming the ANX7625 can also output DisplayPort directly without going
through USB Type-C (I can't verify that without the datasheet), I think
you should use two output ports, one for USB Type-C and one for
DisplayPort. The extcon-supported and internal-pannel-supported
properties should be removed, and deduced from the connect output port.
>
Re: [HELP REQUESTED from the community] Was: Staging status of speakup
On Wed, Sep 18, 2019 at 01:30:33PM -0700, Gregory Nowak wrote: > > Extra line between each attribute (before the "What:" line) would be > > nice. > > In a previous post above, you wrote: > On Mon, Sep 16, 2019 at 04:11:00PM +0200, Greg Kroah-Hartman wrote: > > Anyway, please put the Description: lines without a blank after that, > > with the description text starting on that same line. > > I understood that to mean that the description text should start on > the same line, and the blank lines after the description text should > be removed. I've put them back in. Someone more familiar with the > speakup code will have to dig into it to resolve the TODO items I > suppose. No problem, this looks good to me. If someone wants to turn this into a patch adding it to the drivers/staging/speakup/ directory, I'll be glad to take it and it will allow others to fill in the TODO entries easier. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
