date:20201115

[PATCH] staging: rtl8188eu: clean up the useless code

2020-11-15 Thread xiakaixu1987

From: Kaixu Xia 

The two bool variables singletone and carrier_sup are always false
and the following if statement can't be true, these code are useless,
so remove them.

Reported-by: Tosk Robot 
Signed-off-by: Kaixu Xia 
---
 drivers/staging/rtl8188eu/hal/phy.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/phy.c 
b/drivers/staging/rtl8188eu/hal/phy.c
index a970189ba8c6..a664bff370bb 100644
--- a/drivers/staging/rtl8188eu/hal/phy.c
+++ b/drivers/staging/rtl8188eu/hal/phy.c
@@ -1200,7 +1200,6 @@ void rtl88eu_phy_iq_calibrate(struct adapter *adapt, bool 
recovery)
bool pathaok, pathbok;
s32 reg_e94, reg_e9c, reg_ea4, reg_eb4, reg_ebc, reg_ec4;
bool is12simular, is13simular, is23simular;
-   bool singletone = false, carrier_sup = false;
u32 iqk_bb_reg_92c[IQK_BB_REG_NUM] = {
rOFDM0_XARxIQImbalance, rOFDM0_XBRxIQImbalance,
rOFDM0_ECCAThreshold, rOFDM0_AGCRSSITable,
@@ -1214,9 +1213,6 @@ void rtl88eu_phy_iq_calibrate(struct adapter *adapt, bool 
recovery)
if (!(dm_odm->SupportAbility & ODM_RF_CALIBRATION))
return;
 
-   if (singletone || carrier_sup)
-   return;
-
if (recovery) {
ODM_RT_TRACE(dm_odm, ODM_COMP_INIT, ODM_DBG_LOUD,
 ("phy_iq_calibrate: Return due to recovery!\n"));
@@ -1312,14 +1308,11 @@ void rtl88eu_phy_iq_calibrate(struct adapter *adapt, 
bool recovery)
 
 void rtl88eu_phy_lc_calibrate(struct adapter *adapt)
 {
-   bool singletone = false, carrier_sup = false;
u32 timeout = 2000, timecount = 0;
struct odm_dm_struct *dm_odm = &adapt->HalData->odmpriv;
 
if (!(dm_odm->SupportAbility & ODM_RF_CALIBRATION))
return;
-   if (singletone || carrier_sup)
-   return;
 
while (*dm_odm->pbScanInProcess && timecount < timeout) {
mdelay(50);
-- 
2.20.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

2020-11-15 Thread Dmitry Osipenko

13.11.2020 19:35, Thierry Reding пишет:
> On Fri, Nov 13, 2020 at 01:14:45AM +0300, Dmitry Osipenko wrote:
>> 12.11.2020 23:43, Thierry Reding пишет:
 The difference in comparison to using voltage regulator directly is
 minimal, basically the core-supply phandle is replaced is replaced with
 a power-domain phandle in a device tree.
>>> These new power-domain handles would have to be added to devices that
>>> potentially already have a power-domain handle, right? Isn't that going
>>> to cause issues? I vaguely recall that we already have multiple power
>>> domains for the XUSB controller and we have to jump through extra hoops
>>> to make that work.
>>
>> I modeled the core PD as a parent of the PMC sub-domains, which
>> presumably is a correct way to represent the domains topology.
>>
>> https://gist.github.com/digetx/dfd92c7f7e0aa6cef20403c4298088d7
>>
 The only thing which makes me feel a bit uncomfortable is that there is
 no real hardware node for the power domain node in a device-tree.
>>> Could we anchor the new power domain at the PMC for example? That would
>>> allow us to avoid the "virtual" node.
>>
>> I had a thought about using PMC for the core domain, but not sure
>> whether it will be an entirely correct hardware description. Although,
>> it will be nice to have it this way.
>>
>> This is what Tegra TRM says about PMC:
>>
>> "The Power Management Controller (PMC) block interacts with an external
>> or Power Manager Unit (PMU). The PMC mostly controls the entry and exit
>> of the system from different sleep modes. It provides power-gating
>> controllers for SOC and CPU power-islands and also provides scratch
>> storage to save some of the context during sleep modes (when CPU and/or
>> SOC power rails are off). Additionally, PMC interacts with the external
>> Power Manager Unit (PMU)."
>>
>> The core voltage regulator is a part of the PMU.
>>
>> Not all core SoC devices are behind PMC, IIUC.
> 
> There are usually some SoC devices that are always-on. Things like the
> RTC for example, can never be power-gated, as far as I recall. On newer
> chips there are usually many more blocks that can't be powergated at
> all.

The RTC is actually a special power domain on Tegra, it's not a part of
the CORE domain, they are separate from each other.

We need to know what blocks belong to a power domain and what's the
power topology of these blocks. I think we already have this knowledge,
so it shouldn't be a problem.

>>> On the other hand, if we were to
>>> use a regulator, we'd be adding a node for that, right? So isn't this
>>> effectively going to be the same node if we use a power domain? Both
>>> software constructs are using the same voltage regulator, so they should
>>> be able to be described by the same device tree node, shouldn't they?
>>
>> I'm not exactly sure what you're meaning by "use a regulator" and "we'd
>> be adding a node for that", could you please clarify? This v1 approach
>> uses a core-supply phandle (i.e. regulator is used), it doesn't require
>> extra nodes.
> 
> What I meant to say was that the actual supply voltage is generated by
> some device (typically one of the SD outputs of the PMIC). Whether we
> model this as a power domain or a regulator doesn't really matter,
> right? So I'm wondering if the device that generates the voltage should
> be the power domain provider, just like it is the provider of the
> regulator if this was modelled as a regulator.

Technically this could be done and it shouldn't be difficult to add
GENPD support to the regulator framework, but I think this is an
inaccurate hardware description.

It shouldn't be correct to describe internal SoC parts as
directly-connected to an external voltage regulator. The core voltage
regulator is connected to a one of several power rails of the Tegra
chip. There is no good way to describe hardware in terms of voltage
regulators, hence that's why this v1 series added a core-supply to each
SoC component of each board's DT individually.

It's actually one of the benefits of using a separate DT node for the
power-domain, which describes the "Tegra Core" part of the Tegra SoC,
and thus, it all stays within tegra.dtsi. This means that PD explicitly
belongs to the SoC internals in oppose to describing PD like it's an
external/off-chip component.

Initially I didn't like much that there is no hardware address to back
up the power domain node in a DT, but actually there is no address for
the power rail. Hence it should be better to describe hardware by
keeping PD internally to the SoC. Note that potentially PD may require
knowledge about specifics of a particular SoC, while external regulator
doesn't belong to a SoC. Also, I guess technically there could be
multiple external regulators which power a single SoC rail.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/3] clk/sunxi/media: Fix builds with COMMON_CLK and HAVE_LEGACY_CLK

2020-11-15 Thread Krzysztof Kozlowski

Hi,

Multiple configurations create unbuildable config by selecting
COMMON_CLK and HAVE_LEGACY_CLK.  The first simply should not be
selected.

The patches 2/3 and 3/3 address this specific problem.  I performed few
compile tests and I am still building other configurations, therefore
they were marked as RFC.

Best regards,
Krzysztof


Krzysztof Kozlowski (3):
  clk: fix redefinition of clk_prepare on MIPS with HAVE_LEGACY_CLK
  ARM: sunxi: do not select COMMON_CLK to fix builds
  media: atomisp: do not select COMMON_CLK to fix builds

 arch/arm/mach-sunxi/Kconfig   | 1 +
 drivers/clk/clk.c | 4 
 drivers/staging/media/atomisp/Kconfig | 2 +-
 sound/soc/sunxi/Kconfig   | 2 +-
 4 files changed, 7 insertions(+), 2 deletions(-)

-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] clk: fix redefinition of clk_prepare on MIPS with HAVE_LEGACY_CLK

2020-11-15 Thread Krzysztof Kozlowski

COMMON_CLK even though is a user-selectable symbol, is still selected by
multiple other config options.  COMMON_CLK should not be used when
legacy clocks are provided by architecture, so it correctly depends on
!HAVE_LEGACY_CLK.

However it is possible to create a config which selects both COMMON_CLK
(by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (by SOC_RT305X) which leads to
compile errors (MIPS architecture):

drivers/clk/clk.c:855:6: error: redefinition of ‘clk_unprepare’
In file included from drivers/clk/clk.c:9:
include/linux/clk.h:263:20: note: previous definition of ‘clk_unprepare’ 
was here

The definitions clk_bulk_prepare() (and unprepare) already have proper
surrounding #ifdef so add them also for clk_prepare()/clk_unprepare().

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/clk/clk.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f83dac54ed85..f4f68c7c2fb5 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -841,6 +841,7 @@ static void clk_core_unprepare_lock(struct clk_core *core)
clk_prepare_unlock();
 }
 
+#ifdef CONFIG_HAVE_CLK_PREPARE
 /**
  * clk_unprepare - undo preparation of a clock source
  * @clk: the clk being unprepared
@@ -860,6 +861,7 @@ void clk_unprepare(struct clk *clk)
clk_core_unprepare_lock(clk->core);
 }
 EXPORT_SYMBOL_GPL(clk_unprepare);
+#endif
 
 static int clk_core_prepare(struct clk_core *core)
 {
@@ -921,6 +923,7 @@ static int clk_core_prepare_lock(struct clk_core *core)
return ret;
 }
 
+#ifdef CONFIG_HAVE_CLK_PREPARE
 /**
  * clk_prepare - prepare a clock source
  * @clk: the clk being prepared
@@ -941,6 +944,7 @@ int clk_prepare(struct clk *clk)
return clk_core_prepare_lock(clk->core);
 }
 EXPORT_SYMBOL_GPL(clk_prepare);
+#endif /* CONFIG_HAVE_CLK_PREPARE */
 
 static void clk_core_disable(struct clk_core *core)
 {
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC 2/3] ARM: sunxi: do not select COMMON_CLK to fix builds

2020-11-15 Thread Krzysztof Kozlowski

COMMON_CLK is a user-selectable option with its own dependencies.  The
most important dependency is !HAVE_LEGACY_CLK.  User-selectable drivers
should not select COMMON_CLK because they will create a dependency cycle
and build failures.  For example on MIPS a configuration with COMMON_CLK
(selected by SND_SUN8I_CODEC) and HAVE_LEGACY_CLK (selected by
SOC_RT305X) is possible:

  WARNING: unmet direct dependencies detected for COMMON_CLK
Depends on [n]: !HAVE_LEGACY_CLK [=y]
Selected by [y]:
- SND_SUN8I_CODEC [=y] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] &&
  (ARCH_SUNXI || COMPILE_TEST [=y]) && OF [=y] && (MACH_SUN8I || ARM64 && 
ARCH_SUNXI || COMPILE_TEST [=y])

/usr/bin/mips-linux-gnu-ld: drivers/clk/clk.o: in function `clk_set_rate':
(.text+0xaeb4): multiple definition of `clk_set_rate'; 
arch/mips/ralink/clk.o:(.text+0x88): first defined here

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/mach-sunxi/Kconfig | 1 +
 sound/soc/sunxi/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index eeadb1a4dcfe..4d9f9b6d329d 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -4,6 +4,7 @@ menuconfig ARCH_SUNXI
depends on ARCH_MULTI_V5 || ARCH_MULTI_V7
select ARCH_HAS_RESET_CONTROLLER
select CLKSRC_MMIO
+   select COMMON_CLK
select GENERIC_IRQ_CHIP
select GPIOLIB
select PINCTRL
diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 69b9d8515335..ddcaaa98d3cb 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -14,7 +14,7 @@ config SND_SUN8I_CODEC
tristate "Allwinner SUN8I audio codec"
depends on OF
depends on MACH_SUN8I || (ARM64 && ARCH_SUNXI) || COMPILE_TEST
-   select COMMON_CLK
+   depends on COMMON_CLK
select REGMAP_MMIO
help
  This option enables the digital part of the internal audio codec for
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC 3/3] media: atomisp: do not select COMMON_CLK to fix builds

2020-11-15 Thread Krzysztof Kozlowski

COMMON_CLK is a user-selectable option with its own dependencies.  The
most important dependency is !HAVE_LEGACY_CLK.  User-selectable drivers
should not select COMMON_CLK because they will create a dependency cycle
and build failures.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/staging/media/atomisp/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/Kconfig 
b/drivers/staging/media/atomisp/Kconfig
index 37577bb72998..742edb261d85 100644
--- a/drivers/staging/media/atomisp/Kconfig
+++ b/drivers/staging/media/atomisp/Kconfig
@@ -2,9 +2,9 @@
 menuconfig INTEL_ATOMISP
bool "Enable support to Intel Atom ISP camera drivers"
depends on X86 && EFI && PCI && ACPI
+   depends on COMMON_CLK
select IOSF_MBI
select MEDIA_CONTROLLER
-   select COMMON_CLK
help
  Enable support for the Intel ISP2 camera interfaces and MIPI
  sensor drivers.
-- 
2.25.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-15 Thread Dmitry Osipenko

13.11.2020 20:28, Mark Brown пишет:
> On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
>> 13.11.2020 19:15, Mark Brown пишет:
> 
>>> My point here is that the driver shouldn't be checking for a dummy
>>> regulator, the driver should be checking the features that are provided
>>> to it by the regulator and handling those.
> 
>> I understand yours point, but then we need dummy regulator to provide
>> all the features, and currently it does the opposite.
> 
> As could any other regulator?

Yes

>>> It doesn't matter if this is
>>> a dummy regulator or an actual regulator with limited features, the
>>> effect is the same and the handling should be the same.  If the driver
>>> is doing anything to handle dummy regulators explicitly as dummy
>>> regulators it is doing it wrong.
> 
>> It matters because dummy regulator errors out all checks and changes
>> other than enable/disable, instead of accepting them. If we could add an
>> option for dummy regulator to succeed all the checks and accept all the
>> values, then it could become more usable.
> 
> I'm a bit confused here TBH - I'm not sure I see a substantial
> difference between a consumer detecting that it can't set any voltages
> at all and the handling for an optional regulator.  Either way if it's
> going to carry on and assume that whatever voltage is there works for
> everything it boils down to setting a flag saying to skip the set
> voltage operation.  I think you are too focused on the specific
> implementation you currently have here.
> 
> We obviously can't just accept voltage change operations when we've no
> idea what the current voltage of the device is.
> 
>>> To repeat you should *only* be using regulator_get_optional() in the
>>> case where the supply may be physically absent which is not the case
>>> here.
>>
>> Alright, but then we either need to improve regulator core to make dummy
>> regulator a bit more usable, or continue to work around it in drivers.
>> What should we do?
> 
> As I keep saying the consumer driver should be enumerating the voltages
> it can set, if it can't find any and wants to continue then it can just
> skip setting voltages later on.  If only some are unavailable then it
> probably wants to eliminate those specific OPPs instead.

I'm seeing a dummy regulator as a helper for consumer drivers which
removes burden of handling an absent (optional) regulator. Is this a
correct understanding of a dummy regulator?

Older DTBs don't have a regulator and we want to keep them working. This
is equal to a physically absent regulator and in this case it's an
optional regulator, IMO.

Consumer drivers definitely should check voltages, but this should be
done only for a physical regulator.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 0/6] ARM: dts: sun8i: v3s: Enable video decoder

2020-11-15 Thread Martin Cerveny


Hello.

On Thu, 5 Nov 2020, Hans Verkuil wrote:


Hi Martin,

On 12/09/2020 16:30, Martin Cerveny wrote:

First patch extends cedrus capability to all decoders
because V3s missing MPEG2 decoder.

Next two patches add system control node (SRAM C1) and
next three patches add support for Cedrus VPU.

Tested on "Lichee Zero" V3s platform with testing LCD patch
( https://github.com/mcerveny/linux/tree/v3s_videocodec_v4 )
and V4L2 raw API testing utility
( https://github.com/mcerveny/v4l2-request-test ):
- enabled LCD (DRM dual VI and sigle UI planes)
- added RGB panel
- enabled PWM

There is low memory on V3s (64MB) and maximum must be available to CMA:
- CONFIG_CMA_SIZE_MBYTES=28
- add swap to swapout other processes
- decrease buffers in v4l2-request-test (.buffers_count from 16 to 6)

Only H.264 decoder working - MPEG and H.265 unsupported by V3s,
JPEG/MJPEG still unimplemented, encoder unimplemented


When I tried to merged these patches I got merge conflicts.

Possibly due to other 5.10 changes, but certainly because of conflicts
with patches from Jernej:

https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-4-jernej.skra...@siol.net/
https://patchwork.linuxtv.org/project/linux-media/patch/20200825173523.1289379-5-jernej.skra...@siol.net/

I've merged Jerne's patches and posted a PR for that:
https://patchwork.linuxtv.org/project/linux-media/patch/f3b8e5e2-5f0e-fb6f-e5b2-7f44f7e36...@xs4all.nl/

Can you rebase your patches on top of my branch that contains Jernej's patches?

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=for-v5.11e

Once my PR is merged into the media_tree master I can take your rebased
patches.


I updated patches:
https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e

BUT, commit (555 commits) for v5.10-1
https://github.com/torvalds/linux/commit/fd5c32d80884268a381ed0e67cccef0b3d37750b
disrupts usability of Cedrus H.264 (at least for my Allwinner V3s):

1) colors are disrupted

There are missing some initialization now.

If I use "5.9" compatible code
(last bisect good point 
https://github.com/torvalds/linux/commit/647412daeb454b6dad12a6c6961ab90aac9e5d29
 )
then reboot (not power-off!) and use new code 
( https://github.com/mcerveny/linux/tree/media_tree_for-v5.11e )

and colors are OK.

2) decoding of complex streams fails

( https://github.com/mcerveny/v4l2-request-test/tree/v5.10 )
- bbb-h264-all-i-32 - OK
- bbb-h264-32 - bad from frame 5
- bbb-h264-high-32 - bad from frame 6

best regards,
Martin


Changes since v1:
- patch 0005 rename
- added testing description

Martin Cerveny (6):
  media: cedrus: Register all codecs as capability
  dt-bindings: sram: allwinner,sun4i-a10-system-control: Add V3s
compatibles
  ARM: dts: sun8i: v3s: Add node for system control
  media: cedrus: Add support for V3s
  dt-bindings: media: cedrus: Add V3s compatible
  ARM: dts: sun8i: v3s: Add video engine node

 .../allwinner,sun4i-a10-video-engine.yaml |  1 +
 .../allwinner,sun4i-a10-system-control.yaml   |  6 
 arch/arm/boot/dts/sun8i-v3s.dtsi  | 33 +++
 drivers/staging/media/sunxi/cedrus/cedrus.c   | 28 +++-
 drivers/staging/media/sunxi/cedrus/cedrus.h   |  2 ++
 .../staging/media/sunxi/cedrus/cedrus_video.c |  2 ++
 6 files changed, 71 insertions(+), 1 deletion(-)




___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] media: meson: vdec: add G12/SM1 to module description

2020-11-15 Thread Christian Hewitt

The meson vdec driver also supports Amlogic G12/SM1 hardware.

Signed-off-by: Christian Hewitt 
---
 drivers/staging/media/meson/vdec/vdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/meson/vdec/vdec.c 
b/drivers/staging/media/meson/vdec/vdec.c
index 5ccb3846c879..5d4db7a5b4b5 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -1131,6 +1131,6 @@ static struct platform_driver meson_vdec_driver = {
 };
 module_platform_driver(meson_vdec_driver);
 
-MODULE_DESCRIPTION("Meson video decoder driver for GXBB/GXL/GXM");
+MODULE_DESCRIPTION("Meson video decoder driver for GXBB/GXL/GXM/G12/SM1");
 MODULE_AUTHOR("Maxime Jourdan ");
 MODULE_LICENSE("GPL");
-- 
2.17.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8188eu: clean up the useless code

Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

[PATCH 0/3] clk/sunxi/media: Fix builds with COMMON_CLK and HAVE_LEGACY_CLK

[PATCH 1/3] clk: fix redefinition of clk_prepare on MIPS with HAVE_LEGACY_CLK

[RFC 2/3] ARM: sunxi: do not select COMMON_CLK to fix builds

[RFC 3/3] media: atomisp: do not select COMMON_CLK to fix builds

Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

Re: [PATCH v2 0/6] ARM: dts: sun8i: v3s: Enable video decoder

[PATCH] media: meson: vdec: add G12/SM1 to module description

9 matches

Site Navigation

Mail list logo

Footer information