Re: [PATCH 2/6] mfd: da9063: Replace model with type
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-randconfig-x002-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:10:0,
from drivers//regulator/da9063-regulator.c:16:
drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
drivers//regulator/da9063-regulator.c:744:12: error: 'const struct
da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
if (model->dev_model == da9063->type)
^~
drivers//regulator/da9063-regulator.c:744:12: error: 'const struct
da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^
include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
if (model->dev_model == da9063->type)
^~
drivers//regulator/da9063-regulator.c:744:12: error: 'const struct
da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^
include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
if (model->dev_model == da9063->type)
^~
drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no
member named 'model'
da9063->model);
^~
vim +/if +744 drivers//regulator/da9063-regulator.c
715
716 static int da9063_regulator_probe(struct platform_device *pdev)
717 {
718 struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
719 struct da9063_pdata *da9063_pdata =
dev_get_platdata(da9063->dev);
720 struct of_regulator_match *da9063_reg_matches = NULL;
721 struct da9063_regulators_pdata *regl_pdata;
722 const struct da9063_dev_model *model;
723 struct da9063_regulators *regulators;
724 struct da9063_regulator *regl;
725 struct regulator_config config;
726 bool bcores_merged, bmem_bio_merged;
727 int id, irq, n, n_regulators, ret, val;
728 size_t size;
729
730 regl_pdata = da9063_pdata ? da9063_pdata->regulators_pdata :
NULL;
731
732 if (!regl_pdata)
733 regl_pdata = da9063_parse_regulators_dt(pdev,
734
&da9063_reg_matches);
735
736 if (IS_ERR(regl_pdata) || regl_pdata->n_regulators == 0) {
737 dev_err(&pdev->dev,
738 "No regulators defined for the platform\n");
739 return -ENODEV;
740 }
741
742 /* Find regulators set for particular device model */
743 for (model = regulators_models; model->regulator_info; model++)
{
> 744 if (model->dev_model == da9063->type)
745 break;
746 }
747 if (!model->regulator_info) {
748 dev_err(&pdev->dev, "Chip model not recognised (%u)\n",
749 da9063->model);
750 return -ENODEV;
751 }
752
753 ret = regmap_read(da9063->regmap, DA9063_REG_CONFIG_H, &val);
754 if (ret < 0) {
755 dev_err(&pdev->dev,
756 "Error while reading BUCKs configuration\n");
757 return ret;
758 }
759 bcores_merged = val & DA9063_BCORE_MERGE;
760
Re: [PATCH 2/6] mfd: da9063: Replace model with type
On 05/26/2018 11:16 AM, kbuild test robot wrote: > Hi Marek, > > I love your patch! Perhaps something to improve: > > [auto build test WARNING on ljones-mfd/for-mfd-next] > [also build test WARNING on v4.17-rc6] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613 > base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > for-mfd-next > config: x86_64-randconfig-x002-201820 (attached as .config) > compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All warnings (new ones prefixed by >>): > >In file included from include/linux/kernel.h:10:0, > from drivers//regulator/da9063-regulator.c:16: >drivers//regulator/da9063-regulator.c: In function > 'da9063_regulator_probe': >drivers//regulator/da9063-regulator.c:744:12: error: 'const struct > da9063_dev_model' has no member named 'dev_model' > if (model->dev_model == da9063->type) >^ >include/linux/compiler.h:58:30: note: in definition of macro '__trace_if' > if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ > ^~~~ >>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro >>> 'if' > if (model->dev_model == da9063->type) > ^~ >drivers//regulator/da9063-regulator.c:744:12: error: 'const struct > da9063_dev_model' has no member named 'dev_model' > if (model->dev_model == da9063->type) >^ >include/linux/compiler.h:58:42: note: in definition of macro '__trace_if' > if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ > ^~~~ >>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro >>> 'if' > if (model->dev_model == da9063->type) > ^~ >drivers//regulator/da9063-regulator.c:744:12: error: 'const struct > da9063_dev_model' has no member named 'dev_model' > if (model->dev_model == da9063->type) >^ >include/linux/compiler.h:69:16: note: in definition of macro '__trace_if' > __r = !!(cond); \ >^~~~ >>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro >>> 'if' > if (model->dev_model == da9063->type) > ^~ >drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has > no member named 'model' >da9063->model); > ^~ > > vim +/if +744 drivers//regulator/da9063-regulator.c Is it testing this patch without the other patches in the series or at least 1/6 ? -- Best regards, Marek Vasut
Re: [PATCH] PCI: rcar: Clean up PHY init on failure
On 5/25/2018 9:33 PM, Marek Vasut wrote:
If the Gen3 PHY fails to power up, the code does not undo the
initialization caused by phy_init(). Add the missing failure
handling to the rcar_pcie_phy_init_gen3() function.
Signed-off-by: Marek Vasut
Reported-by: Geert Uytterhoeven
Cc: Geert Uytterhoeven
Cc: Lorenzo Pieralisi
Cc: Phil Edworthy
Cc: Simon Horman
Cc: Wolfram Sang
Cc: linux-renesas-soc@vger.kernel.org
Fixes: 517ca93a7159 ("PCI: rcar: Add R-Car gen3 PHY support")
[...]
Oops, it's my sloppy coding again. Sorry about that...
MBR, Sergei
Re: [PATCH 2/6] mfd: da9063: Replace model with type
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-randconfig-x011-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>> drivers/regulator/da9063-regulator.c:744:12: error: 'const struct
>> da9063_dev_model' has no member named 'dev_model'
if (model->dev_model == da9063->type)
^~
>> drivers/regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no
>> member named 'model'
da9063->model);
^~
vim +744 drivers/regulator/da9063-regulator.c
715
716 static int da9063_regulator_probe(struct platform_device *pdev)
717 {
718 struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
719 struct da9063_pdata *da9063_pdata =
dev_get_platdata(da9063->dev);
720 struct of_regulator_match *da9063_reg_matches = NULL;
721 struct da9063_regulators_pdata *regl_pdata;
722 const struct da9063_dev_model *model;
723 struct da9063_regulators *regulators;
724 struct da9063_regulator *regl;
725 struct regulator_config config;
726 bool bcores_merged, bmem_bio_merged;
727 int id, irq, n, n_regulators, ret, val;
728 size_t size;
729
730 regl_pdata = da9063_pdata ? da9063_pdata->regulators_pdata :
NULL;
731
732 if (!regl_pdata)
733 regl_pdata = da9063_parse_regulators_dt(pdev,
734
&da9063_reg_matches);
735
736 if (IS_ERR(regl_pdata) || regl_pdata->n_regulators == 0) {
737 dev_err(&pdev->dev,
738 "No regulators defined for the platform\n");
739 return -ENODEV;
740 }
741
742 /* Find regulators set for particular device model */
743 for (model = regulators_models; model->regulator_info; model++)
{
> 744 if (model->dev_model == da9063->type)
745 break;
746 }
747 if (!model->regulator_info) {
748 dev_err(&pdev->dev, "Chip model not recognised (%u)\n",
> 749 da9063->model);
750 return -ENODEV;
751 }
752
753 ret = regmap_read(da9063->regmap, DA9063_REG_CONFIG_H, &val);
754 if (ret < 0) {
755 dev_err(&pdev->dev,
756 "Error while reading BUCKs configuration\n");
757 return ret;
758 }
759 bcores_merged = val & DA9063_BCORE_MERGE;
760 bmem_bio_merged = val & DA9063_BUCK_MERGE;
761
762 n_regulators = model->n_regulators;
763 if (bcores_merged)
764 n_regulators -= 2; /* remove BCORE1, BCORE2 */
765 else
766 n_regulators--;/* remove BCORES_MERGED */
767 if (bmem_bio_merged)
768 n_regulators -= 2; /* remove BMEM, BIO */
769 else
770 n_regulators--;/* remove BMEM_BIO_MERGED */
771
772 /* Allocate memory required by usable regulators */
773 size = sizeof(struct da9063_regulators) +
774 n_regulators * sizeof(struct da9063_regulator);
775 regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
776 if (!regulators)
777 return -ENOMEM;
778
779 regulators->n_regulators = n_regulators;
780 platform_set_drvdata(pdev, regulators);
781
782 /* Register all regulators declared in platform information */
783 n = 0;
784 id = 0;
785 while (n < regulators->n_regulators) {
786 /* Skip regulator IDs depending on merge mode
configuration */
787 switch (id) {
788 case DA9063_ID_BCORE1:
789 case DA9063_ID_BCORE2:
790 if (bcores_merged) {
791 id
Re: [PATCH v7 5/5] clk: renesas: Renesas R9A06G032 clock driver
Hi Michel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on renesas-drivers/clk-renesas]
[also build test WARNING on v4.17-rc6]
[cannot apply to robh/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Michel-Pollet/dt-bindings-Add-the-r9a06g032-sysctrl-h-file/20180526-154235
base:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
clk-renesas
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/clk/renesas/r9a06g032-clocks.c:430:22: sparse: cast removes address
>> space of expression
>> drivers/clk/renesas/r9a06g032-clocks.c:431:30: sparse: incorrect type in
>> argument 1 (different address spaces) @@expected unsigned int [noderef]
>> [usertype] *reg @@got eref] [usertype] *reg @@
drivers/clk/renesas/r9a06g032-clocks.c:431:30:expected unsigned int
[noderef] [usertype] *reg
drivers/clk/renesas/r9a06g032-clocks.c:431:30:got unsigned int
[usertype] *reg
drivers/clk/renesas/r9a06g032-clocks.c:516:22: sparse: cast removes address
space of expression
drivers/clk/renesas/r9a06g032-clocks.c:528:38: sparse: incorrect type in
argument 2 (different address spaces) @@expected unsigned int [noderef]
[usertype] *reg @@got eref] [usertype] *reg @@
drivers/clk/renesas/r9a06g032-clocks.c:528:38:expected unsigned int
[noderef] [usertype] *reg
drivers/clk/renesas/r9a06g032-clocks.c:528:38:got unsigned int
[usertype] *reg
vim +430 drivers/clk/renesas/r9a06g032-clocks.c
421
422 #define to_r9a06g032_divider(_hw) \
423 container_of(_hw, struct r9a06g032_clk_div, hw)
424
425 static unsigned long r9a06g032_divider_recalc_rate(
426 struct clk_hw *hw,
427 unsigned long parent_rate)
428 {
429 struct r9a06g032_clk_div *clk = to_r9a06g032_divider(hw);
> 430 u32 *reg = ((u32 *)clk->clocks->reg) + clk->reg;
> 431 long div = clk_readl(reg);
432
433 if (div < clk->min)
434 div = clk->min;
435 else if (div > clk->max)
436 div = clk->max;
437 return DIV_ROUND_UP(parent_rate, div);
438 }
439
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Proposal
Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
[RFC PATCH v2 0/2] Implement standard color keying properties for DRM planes
Hello, DRM maintainers! Laurent Pinchart kindly agreed to allow me to pick up his work on the generic colorkey DRM plane property [0]. I've reworked the original patch a tad, hopefully making it flexible enough to cover various HW capabilities. Changes I've made: - Some code clean up and reshuffle. - Took into account some the Ville's Syrjälä review comments to [0]. - The number of common DRM colorkey properties grows from 4 to 9. New properties: - colorkey.mask - colorkey.format - colorkey.inverted-match - colorkey.replacement-mask - colorkey.replacement-format Renamed properties: - colorkey.value -> colorkey.replacement-value - colorkey.mode userspace-property ENUM's got a bit more explicit names, like "src" -> "src-match-src-replace". - No driver-specific modes / properties allowed, all unsupported features are simply rejected by the drivers. This patchset includes initial colorkey property implementation for the older NVIDIA Tegra's. Please review, thanks. [0] https://lists.freedesktop.org/archives/dri-devel/2017-December/160510.html Dmitry Osipenko (2): drm: Add generic colorkey properties drm/tegra: plane: Implement generic colorkey property for older Tegra's drivers/gpu/drm/drm_atomic.c | 36 ++ drivers/gpu/drm/drm_blend.c | 229 ++ drivers/gpu/drm/tegra/dc.c| 31 + drivers/gpu/drm/tegra/dc.h| 7 ++ drivers/gpu/drm/tegra/plane.c | 147 ++ drivers/gpu/drm/tegra/plane.h | 1 + include/drm/drm_blend.h | 3 + include/drm/drm_plane.h | 77 8 files changed, 531 insertions(+) -- 2.17.0
[RFC PATCH v2 2/2] drm/tegra: plane: Implement generic colorkey property for older Tegra's
Color keying allows to draw on top of overlapping planes, like for
example on top of a video plane. Older Tegra's have a limited color
keying capability, such that blending features are reduced when color
keying is enabled. In particular dependent weighting isn't possible,
meaning that cursors plane can't be displayed properly. In most cases
it is more useful to display content on top of video overlay, so
sacrificing mouse cursor in the area of three planes intersection with
colorkey mismatch is a reasonable tradeoff.
This patch implements the generic DRM colorkey property. For the starter
a minimal color keying support is implemented, it is enough to provide
userspace like Opentegra Xorg driver with ability to support color keying
by the XVideo extension.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 31 +++
drivers/gpu/drm/tegra/dc.h| 7 ++
drivers/gpu/drm/tegra/plane.c | 147 ++
drivers/gpu/drm/tegra/plane.h | 1 +
4 files changed, 186 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 31e12a9dfcb8..a5add64e40e2 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -172,6 +172,11 @@ static void tegra_plane_setup_blending_legacy(struct
tegra_plane *plane)
state = to_tegra_plane_state(plane->base.state);
+ if (state->ckey_enabled) {
+ background[0] |= BLEND_COLOR_KEY_0;
+ background[2] |= BLEND_COLOR_KEY_0;
+ }
+
if (state->opaque) {
/*
* Since custom fix-weight blending isn't utilized and weight
@@ -776,6 +781,11 @@ static struct drm_plane *tegra_primary_plane_create(struct
drm_device *drm,
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_DST));
+
return &plane->base;
}
@@ -1053,6 +1063,11 @@ static struct drm_plane
*tegra_dc_overlay_plane_create(struct drm_device *drm,
drm_plane_helper_add(&plane->base, &tegra_plane_helper_funcs);
drm_plane_create_zpos_property(&plane->base, plane->index, 0, 255);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_DST));
+
return &plane->base;
}
@@ -1153,6 +1168,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
{
struct tegra_dc_state *state = to_dc_state(crtc->state);
struct tegra_dc_state *copy;
+ unsigned int i;
copy = kmalloc(sizeof(*copy), GFP_KERNEL);
if (!copy)
@@ -1164,6 +1180,9 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
copy->div = state->div;
copy->planes = state->planes;
+ for (i = 0; i < 2; i++)
+ copy->ckey[i] = state->ckey[i];
+
return ©->base;
}
@@ -1893,6 +1912,18 @@ static void tegra_crtc_atomic_flush(struct drm_crtc
*crtc,
struct tegra_dc *dc = to_tegra_dc(crtc);
u32 value;
+ if (dc->soc->has_legacy_blending) {
+ tegra_dc_writel(dc,
+ state->ckey[0].lower, DC_DISP_COLOR_KEY0_LOWER);
+ tegra_dc_writel(dc,
+ state->ckey[0].upper, DC_DISP_COLOR_KEY0_UPPER);
+
+ tegra_dc_writel(dc,
+ state->ckey[1].lower, DC_DISP_COLOR_KEY1_LOWER);
+ tegra_dc_writel(dc,
+ state->ckey[1].upper, DC_DISP_COLOR_KEY1_UPPER);
+ }
+
value = state->planes << 8 | GENERAL_UPDATE;
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
value = tegra_dc_readl(dc, DC_CMD_STATE_CONTROL);
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index e96f582ca692..8209cb7d598a 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -18,6 +18,11 @@
struct tegra_output;
+struct tegra_dc_color_key_state {
+ u32 lower;
+ u32 upper;
+};
+
struct tegra_dc_state {
struct drm_crtc_state base;
@@ -26,6 +31,8 @@ struct tegra_dc_state {
unsigned int div;
u32 planes;
+
+ struct tegra_dc_color_key_state ckey[2];
};
static inline struct tegra_dc_state *to_dc_state(struct drm_crtc_state *state)
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index 0406c2ef432c..ba08b66d2499 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -57,6 +57,7 @@ tegra_plane_atomic_duplicate_state(struct drm_plane *plane)
co
[RFC PATCH v2 1/2] drm: Add generic colorkey properties
Color keying is the action of replacing pixels matching a given color
(or range of colors) with transparent pixels in an overlay when
performing blitting. Depending on the hardware capabilities, the
matching pixel can either become fully transparent or gain adjustment
of the pixels component values.
Color keying is found in a large number of devices whose capabilities
often differ, but they still have enough common features in range to
standardize color key properties. This commit adds nine generic DRM plane
properties related to the color keying to cover various HW capabilities.
This patch is based on the initial work done by Laurent Pinchart, most of
credits for this patch goes to him.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_atomic.c | 36 ++
drivers/gpu/drm/drm_blend.c | 229 +++
include/drm/drm_blend.h | 3 +
include/drm/drm_plane.h | 77
4 files changed, 345 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 895741e9cd7d..5b808cb68654 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == plane->colorkey.mode_property) {
+ state->colorkey.mode = val;
+ } else if (property == plane->colorkey.min_property) {
+ state->colorkey.min = val;
+ } else if (property == plane->colorkey.max_property) {
+ state->colorkey.max = val;
+ } else if (property == plane->colorkey.format_property) {
+ state->colorkey.format = val;
+ } else if (property == plane->colorkey.mask_property) {
+ state->colorkey.mask = val;
+ } else if (property == plane->colorkey.inverted_match_property) {
+ state->colorkey.inverted_match = val;
+ } else if (property == plane->colorkey.replacement_mask_property) {
+ state->colorkey.replacement_mask = val;
+ } else if (property == plane->colorkey.replacement_value_property) {
+ state->colorkey.replacement_value = val;
+ } else if (property == plane->colorkey.replacement_format_property) {
+ state->colorkey.replacement_format = val;
} else if (property == plane->color_encoding_property) {
state->color_encoding = val;
} else if (property == plane->color_range_property) {
@@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == plane->colorkey.mode_property) {
+ *val = state->colorkey.mode;
+ } else if (property == plane->colorkey.min_property) {
+ *val = state->colorkey.min;
+ } else if (property == plane->colorkey.max_property) {
+ *val = state->colorkey.max;
+ } else if (property == plane->colorkey.format_property) {
+ *val = state->colorkey.format;
+ } else if (property == plane->colorkey.mask_property) {
+ *val = state->colorkey.mask;
+ } else if (property == plane->colorkey.inverted_match_property) {
+ *val = state->colorkey.inverted_match;
+ } else if (property == plane->colorkey.replacement_mask_property) {
+ *val = state->colorkey.replacement_mask;
+ } else if (property == plane->colorkey.replacement_value_property) {
+ *val = state->colorkey.replacement_value;
+ } else if (property == plane->colorkey.replacement_format_property) {
+ *val = state->colorkey.replacement_format;
} else if (property == plane->color_encoding_property) {
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a16a74d7e15e..05e5632ce375 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -107,6 +107,11 @@
* planes. Without this property the primary plane is always below the
cursor
* plane, and ordering between all other planes is undefined.
*
+ * colorkey:
+ * Color keying is set up with drm_plane_create_colorkey_properties().
+ * It adds support for replacing a range of colors with a transparent
+ * color in the plane.
+ *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
@@ -448,3 +453,227 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drm_atomic_normalize_zpos);
+
+static const char * const plane_colo
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
Hi Dimitri,
Thank you for the patch.
I'll review this in details, but as this patch is based on the "[PATCH/RFC
1/4] drm: Add colorkey properties" patch I've submitted, please retain the
authorship, both in the Signed-off-by line, and in the patch author in git.
On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transparent or gain adjustment
> of the pixels component values.
>
> Color keying is found in a large number of devices whose capabilities
> often differ, but they still have enough common features in range to
> standardize color key properties. This commit adds nine generic DRM plane
> properties related to the color keying to cover various HW capabilities.
>
> This patch is based on the initial work done by Laurent Pinchart, most of
> credits for this patch goes to him.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_atomic.c | 36 ++
> drivers/gpu/drm/drm_blend.c | 229 +++
> include/drm/drm_blend.h | 3 +
> include/drm/drm_plane.h | 77
> 4 files changed, 345 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 895741e9cd7d..5b808cb68654 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane, state->rotation = val;
> } else if (property == plane->zpos_property) {
> state->zpos = val;
> + } else if (property == plane->colorkey.mode_property) {
> + state->colorkey.mode = val;
> + } else if (property == plane->colorkey.min_property) {
> + state->colorkey.min = val;
> + } else if (property == plane->colorkey.max_property) {
> + state->colorkey.max = val;
> + } else if (property == plane->colorkey.format_property) {
> + state->colorkey.format = val;
> + } else if (property == plane->colorkey.mask_property) {
> + state->colorkey.mask = val;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + state->colorkey.inverted_match = val;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + state->colorkey.replacement_mask = val;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + state->colorkey.replacement_value = val;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + state->colorkey.replacement_format = val;
> } else if (property == plane->color_encoding_property) {
> state->color_encoding = val;
> } else if (property == plane->color_range_property) {
> @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->rotation;
> } else if (property == plane->zpos_property) {
> *val = state->zpos;
> + } else if (property == plane->colorkey.mode_property) {
> + *val = state->colorkey.mode;
> + } else if (property == plane->colorkey.min_property) {
> + *val = state->colorkey.min;
> + } else if (property == plane->colorkey.max_property) {
> + *val = state->colorkey.max;
> + } else if (property == plane->colorkey.format_property) {
> + *val = state->colorkey.format;
> + } else if (property == plane->colorkey.mask_property) {
> + *val = state->colorkey.mask;
> + } else if (property == plane->colorkey.inverted_match_property) {
> + *val = state->colorkey.inverted_match;
> + } else if (property == plane->colorkey.replacement_mask_property) {
> + *val = state->colorkey.replacement_mask;
> + } else if (property == plane->colorkey.replacement_value_property) {
> + *val = state->colorkey.replacement_value;
> + } else if (property == plane->colorkey.replacement_format_property) {
> + *val = state->colorkey.replacement_format;
> } else if (property == plane->color_encoding_property) {
> *val = state->color_encoding;
> } else if (property == plane->color_range_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index a16a74d7e15e..05e5632ce375 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -107,6 +107,11 @@
> * planes. Without this property the primary plane is always below the
> cursor * plane, and ordering between all other planes is undefined.
> *
> + * colorkey:
> + * Color keying is set up with drm_plane_create_colorkey_properties().
> + * It adds support for replacing a range of colors with a transparent
> + * color in t
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote:
> Hi Dimitri,
And sorry for the spelling mistake :-/
> Thank you for the patch.
>
> I'll review this in details, but as this patch is based on the "[PATCH/RFC
> 1/4] drm: Add colorkey properties" patch I've submitted, please retain the
> authorship, both in the Signed-off-by line, and in the patch author in git.
>
> On Saturday, 26 May 2018 18:56:22 EEST Dmitry Osipenko wrote:
> > Color keying is the action of replacing pixels matching a given color
> > (or range of colors) with transparent pixels in an overlay when
> > performing blitting. Depending on the hardware capabilities, the
> > matching pixel can either become fully transparent or gain adjustment
> > of the pixels component values.
> >
> > Color keying is found in a large number of devices whose capabilities
> > often differ, but they still have enough common features in range to
> > standardize color key properties. This commit adds nine generic DRM plane
> > properties related to the color keying to cover various HW capabilities.
> >
> > This patch is based on the initial work done by Laurent Pinchart, most of
> > credits for this patch goes to him.
> >
> > Signed-off-by: Dmitry Osipenko
> > ---
> >
> > drivers/gpu/drm/drm_atomic.c | 36 ++
> > drivers/gpu/drm/drm_blend.c | 229 +++
> > include/drm/drm_blend.h | 3 +
> > include/drm/drm_plane.h | 77
> > 4 files changed, 345 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 895741e9cd7d..5b808cb68654 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -799,6 +799,24 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane, state->rotation = val;
> >
> > } else if (property == plane->zpos_property) {
> >
> > state->zpos = val;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + state->colorkey.mode = val;
> > + } else if (property == plane->colorkey.min_property) {
> > + state->colorkey.min = val;
> > + } else if (property == plane->colorkey.max_property) {
> > + state->colorkey.max = val;
> > + } else if (property == plane->colorkey.format_property) {
> > + state->colorkey.format = val;
> > + } else if (property == plane->colorkey.mask_property) {
> > + state->colorkey.mask = val;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + state->colorkey.inverted_match = val;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + state->colorkey.replacement_mask = val;
> > + } else if (property == plane->colorkey.replacement_value_property) {
> > + state->colorkey.replacement_value = val;
> > + } else if (property == plane->colorkey.replacement_format_property) {
> > + state->colorkey.replacement_format = val;
> >
> > } else if (property == plane->color_encoding_property) {
> >
> > state->color_encoding = val;
> >
> > } else if (property == plane->color_range_property) {
> >
> > @@ -864,6 +882,24 @@ drm_atomic_plane_get_property(struct drm_plane
> > *plane,
> >
> > *val = state->rotation;
> >
> > } else if (property == plane->zpos_property) {
> >
> > *val = state->zpos;
> >
> > + } else if (property == plane->colorkey.mode_property) {
> > + *val = state->colorkey.mode;
> > + } else if (property == plane->colorkey.min_property) {
> > + *val = state->colorkey.min;
> > + } else if (property == plane->colorkey.max_property) {
> > + *val = state->colorkey.max;
> > + } else if (property == plane->colorkey.format_property) {
> > + *val = state->colorkey.format;
> > + } else if (property == plane->colorkey.mask_property) {
> > + *val = state->colorkey.mask;
> > + } else if (property == plane->colorkey.inverted_match_property) {
> > + *val = state->colorkey.inverted_match;
> > + } else if (property == plane->colorkey.replacement_mask_property) {
> > + *val = state->colorkey.replacement_mask;
> > + } else if (property == plane->colorkey.replacement_value_property) {
> > + *val = state->colorkey.replacement_value;
> > + } else if (property == plane->colorkey.replacement_format_property) {
> > + *val = state->colorkey.replacement_format;
> >
> > } else if (property == plane->color_encoding_property) {
> >
> > *val = state->color_encoding;
> >
> > } else if (property == plane->color_range_property) {
> >
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index a16a74d7e15e..05e5632ce375 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -107,6 +107,11 @@
> >
> > * planes. Without this property th
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 26.05.2018 19:16, Laurent Pinchart wrote: > Hi Dimitri, > > Thank you for the patch. > > I'll review this in details, but as this patch is based on the "[PATCH/RFC > 1/4] drm: Add colorkey properties" patch I've submitted, please retain the > authorship, both in the Signed-off-by line, and in the patch author in git. Okay. /I think/ I've seen requests to do the other way around for the picked up and re-worked patches, though I don't mind at all to keep your authorship. I'll change the authorship in the next iteration. Waiting for you review comments, thanks.
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On 26.05.2018 19:18, Laurent Pinchart wrote: > On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote: >> Hi Dimitri, > > And sorry for the spelling mistake :-/ That's also a kinda correct spelling. No worries ;)
Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops
Hello.
A formal patch review this time...
On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote:
> The change fixes a sleep in atomic context issue, which can be
> always triggered by running 'ethtool -r' command, because
> phy_start_aneg() protects phydev fields by a mutex.
OK so far...
> Another note is that the change implicitly replaces phy_start_aneg()
> with a newer phy_restart_aneg().
Why? Is this necessary to fix the BUG()?
> Signed-off-by: Vladimir Zapolskiy
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 17 +
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> b/drivers/net/ethernet/renesas/ravb_main.c
> index 68f122140966..4a043eb0e2aa 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1150,21 +1150,6 @@ static int ravb_set_link_ksettings(struct net_device
> *ndev,
> return error;
> }
>
> -static int ravb_nway_reset(struct net_device *ndev)
> -{
> - struct ravb_private *priv = netdev_priv(ndev);
> - int error = -ENODEV;
> - unsigned long flags;
> -
> - if (ndev->phydev) {
> - spin_lock_irqsave(&priv->lock, flags);
OK, removing spin_lock_irqsave() fixes the BUG()...
Not sure what we rotect against here anyway, MAC interrupts?
> - error = phy_start_aneg(ndev->phydev);
> - spin_unlock_irqrestore(&priv->lock, flags);
> - }
> -
> - return error;
> -}
> -
> static u32 ravb_get_msglevel(struct net_device *ndev)
> {
> struct ravb_private *priv = netdev_priv(ndev);
> @@ -1377,7 +1362,7 @@ static int ravb_set_wol(struct net_device *ndev, struct
> ethtool_wolinfo *wol)
> }
>
> static const struct ethtool_ops ravb_ethtool_ops = {
> - .nway_reset = ravb_nway_reset,
> + .nway_reset = phy_ethtool_nway_reset,
What does this fix?
> .get_msglevel = ravb_get_msglevel,
> .set_msglevel = ravb_set_msglevel,
> .get_link = ethtool_op_get_link,
MBR, Sergei
Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops
Hello.
A formal patch review this time...
On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote:
> The change fixes a sleep in atomic context issue, which can be
> always triggered by running 'ethtool -r' command, because
> phy_start_aneg() protects phydev fields by a mutex.
OK so far...
> Another note is that the change implicitly replaces phy_start_aneg()
> with a newer phy_restart_aneg().
Why? Is this necessary to fix the BUG()?
> Signed-off-by: Vladimir Zapolskiy
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 17 +
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> b/drivers/net/ethernet/renesas/ravb_main.c
> index 68f122140966..4a043eb0e2aa 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1150,21 +1150,6 @@ static int ravb_set_link_ksettings(struct net_device
> *ndev,
> return error;
> }
>
> -static int ravb_nway_reset(struct net_device *ndev)
> -{
> - struct ravb_private *priv = netdev_priv(ndev);
> - int error = -ENODEV;
> - unsigned long flags;
> -
> - if (ndev->phydev) {
> - spin_lock_irqsave(&priv->lock, flags);
OK, removing spin_lock_irqsave() fixes the BUG()...
Not sure what we rotect against here anyway, MAC interrupts?
> - error = phy_start_aneg(ndev->phydev);
> - spin_unlock_irqrestore(&priv->lock, flags);
> - }
> -
> - return error;
> -}
> -
> static u32 ravb_get_msglevel(struct net_device *ndev)
> {
> struct ravb_private *priv = netdev_priv(ndev);
> @@ -1377,7 +1362,7 @@ static int ravb_set_wol(struct net_device *ndev, struct
> ethtool_wolinfo *wol)
> }
>
> static const struct ethtool_ops ravb_ethtool_ops = {
> - .nway_reset = ravb_nway_reset,
> + .nway_reset = phy_ethtool_nway_reset,
What does this fix?
> .get_msglevel = ravb_get_msglevel,
> .set_msglevel = ravb_set_msglevel,
> .get_link = ethtool_op_get_link,
MBR, Sergei
Re: [PATCH 2/6] ravb: remove custom .get_link_ksettings from ethtool ops
On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change replaces a custom implementation of .get_link_ksettings > callback with a shared phy_ethtool_get_link_ksettings(), note that > &priv->lock wrapping is not needed, because the lock does not > serialize access to phydev fields. No BUG() here, AFAICT. But then this is not a fix but an enhancement. And I would have done that in 2 steps: 1st removing the spinlock code and the 2nd removing the custom method implementation. > Signed-off-by: Vladimir Zapolskiy [...] MBR, Sergei
Re: [PATCH 0/6] ravb/sh_eth: fix sleep in atomic by reusing shared ethtool handlers
On 05/25/2018 09:25 AM, Vladimir Zapolskiy wrote: For ages trivial changes to RAVB and SuperH ethernet links by means of standard 'ethtool' trigger a 'sleeping function called from invalid context' bug, to visualize it on r8a7795 ULCB: % ethtool -r eth0 BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747 in_atomic(): 1, irqs_disabled(): 128, pid: 554, name: ethtool INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<>] (null) hardirqs last disabled at (0): [] copy_process.isra.7.part.8+0x2cc/0x1918 softirqs last enabled at (0): [] copy_process.isra.7.part.8+0x2cc/0x1918 softirqs last disabled at (0): [<>] (null) CPU: 5 PID: 554 Comm: ethtool Not tainted 4.17.0-rc4-arm64-renesas+ #33 Hardware name: Renesas H3ULCB board based on r8a7795 ES2.0+ (DT) Call trace: dump_backtrace+0x0/0x198 show_stack+0x24/0x30 dump_stack+0xb8/0xf4 ___might_sleep+0x1c8/0x1f8 __might_sleep+0x58/0x90 __mutex_lock+0x50/0x890 mutex_lock_nested+0x3c/0x50 phy_start_aneg_priv+0x38/0x180 phy_start_aneg+0x24/0x30 ravb_nway_reset+0x3c/0x68 dev_ethtool+0x3dc/0x2338 dev_ioctl+0x19c/0x490 sock_do_ioctl+0xe0/0x238 sock_ioctl+0x254/0x460 do_vfs_ioctl+0xb0/0x918 ksys_ioctl+0x50/0x80 sys_ioctl+0x34/0x48 __sys_trace_return+0x0/0x4 The root cause is that an attempt to modify ECMR and GECMR registers only when RX/TX function is disabled was too overcomplicated in its original implementation, also processing of an optional Link Change interrupt added even more complexity, as a result the implementation was error prone. The new locking scheme is confirmed to be correct by dumping driver specific and generic PHY framework function calls with aid of ftrace while running more or less advanced tests. Please note that sh_eth patches from the series were built-tested only. On purpose I do not add Fixes tags, the reused PHY handlers were added way later than the fixed problems were firstly found in the drivers. >>> >>>I think you went one step too far with these fixes. On the first glance, >>> the real fixes are to remove grabbing/releasing the spinlock for the >>> duration >>> of the phylib calls. Am I right? If so, making use of the new phylib APIs >>> would be a further enhancement, it's not needed for fixing the splats per >>> se... >> >>Note that I hadn't looked at the patches #3/#6 at the time of writing >> this; >> those seem to be more complicated than the rest. > > Right, the simplistic approach of just removing the held spinlock does > not fit well into the overall lame locking model found in the driver. Yet you only try fixing it in the patches #3 and #6. I was talking about the patches #1 and #4 mostly (#2 and #5 turned out to be non-fixes). > The thing is that I would prefer to exhibit 'remove custom callbacks' > side of the changes as it is done now, and fixing severe 'invalid contex' > bugs is left as a valuable side effect. I may attempt to find enough > free time to follow your instructions, but frankly speaking I don't > see it beneficial to split a single good all-sufficient change into > three or more: removal of spinlocks, replacement of phy_start_aneg(), > then a non-functional clean-up. Yes, I would prefer these step-by-step changes. > Bikeshedding isn't my preference, This is not about bikeshedding. What you are trying to do clearly violates the 2 basic principles of the kernel development: "don't mix fixes and enhancements" and "do one thing per patch". > but a report about technical flaws related to the published changes > is appreciated, otherwise let me ask you to accept the changes as is, > secondary optimizations can be done on top of them. No, I'll certainly have to NAK patches #1/#3 in their current form. I'm yet to review patches #3/#6... anyway, if you lack the time to do things properly, I'll have to take this burden on my shoulders (giving you credits). Yet I'm basically is in the same situation as you -- I have to spend my copiuos free time on the large patch sets (like yours) and I'm still having some cleanups to sh_eth cooking here (which I'll most probably have to defer)... > -- > With best wishes, > Vladimir MBR, Sergei
Re: [PATCH 1/6] ravb: remove custom .nway_reset from ethtool ops
On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change fixes a sleep in atomic context issue, which can be > always triggered by running 'ethtool -r' command, because > phy_start_aneg() protects phydev fields by a mutex. BTW, I was unable to trigger the BUG() with 'ethtool -r eth0' where 'eth0' is EtherAVB. What am I doing wrong? :-) MBR, Sergei
Re: [PATCH 4/6] sh_eth: remove custom .nway_reset from ethtool ops
On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote: > The change fixes a sleep in atomic context issue, which can be > always triggered by running 'ethtool -r' command, because > phy_start_aneg() protects phydev fields by a mutex. Again, I'm unable to reproduce this BUG()... > Another note is that the change implicitly replaces phy_start_aneg() > with a newer phy_restart_aneg(). > > Signed-off-by: Vladimir Zapolskiy [...] MBR, Sergei
Re: [PATCH 4/6] sh_eth: remove custom .nway_reset from ethtool ops
On 05/26/2018 09:46 PM, Sergei Shtylyov wrote: >> The change fixes a sleep in atomic context issue, which can be >> always triggered by running 'ethtool -r' command, because >> phy_start_aneg() protects phydev fields by a mutex. > >Again, I'm unable to reproduce this BUG()... Now I can! I started to suspect this check needs to be specifically enabled under the Kernel Hacking menu, and it turned out to be so... >> Another note is that the change implicitly replaces phy_start_aneg() >> with a newer phy_restart_aneg(). >> >> Signed-off-by: Vladimir Zapolskiy > [...] MBR, Sergei
Re: [PATCH 3/6] ravb: remove custom .set_link_ksettings from ethtool ops
On 05/24/2018 02:11 PM, Vladimir Zapolskiy wrote:
> The change replaces a custom implementation of .set_link_ksettings
> callback with a shared phy_ethtool_set_link_ksettings(), this fixes
> sleep in atomic context bug, which is encountered every time when link
> settings are changed by ethtool.
Seeing it now...
> Now duplex mode setting is enforced in ravb_adjust_link() only, also
> now TX/RX is disabled when link is put down or modifications to E-MAC
> registers ECMR and GECMR are expected for both cases of checked and
> ignored link status pin state from E-MAC interrupt handler.
>
> Signed-off-by: Vladimir Zapolskiy
> ---
> drivers/net/ethernet/renesas/ravb_main.c | 58
> +---
> 1 file changed, 15 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> b/drivers/net/ethernet/renesas/ravb_main.c
> index 3d91caa44176..0d811c02ff34 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -980,6 +980,13 @@ static void ravb_adjust_link(struct net_device *ndev)
> struct ravb_private *priv = netdev_priv(ndev);
> struct phy_device *phydev = ndev->phydev;
> bool new_state = false;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> +
> + /* Disable TX and RX right over here, if E-MAC change is ignored */
> + if (priv->no_avb_link)
> + ravb_rcv_snd_disable(ndev);
>
> if (phydev->link) {
> if (phydev->duplex != priv->duplex) {
> @@ -997,18 +1004,21 @@ static void ravb_adjust_link(struct net_device *ndev)
> ravb_modify(ndev, ECMR, ECMR_TXF, 0);
> new_state = true;
> priv->link = phydev->link;
> - if (priv->no_avb_link)
> - ravb_rcv_snd_enable(ndev);
> }
> } else if (priv->link) {
> new_state = true;
> priv->link = 0;
> priv->speed = 0;
> priv->duplex = -1;
> - if (priv->no_avb_link)
> - ravb_rcv_snd_disable(ndev);
> }
>
> + /* Enable TX and RX right over here, if E-MAC change is ignored */
> + if (priv->no_avb_link && phydev->link)
> + ravb_rcv_snd_enable(ndev);
> +
> + mmiowb();
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
I like this part. :-)
> if (new_state && netif_msg_link(priv))
> phy_print_status(phydev);
> }
> @@ -1096,44 +1106,6 @@ static int ravb_phy_start(struct net_device *ndev)
> return 0;
> }
>
> -static int ravb_set_link_ksettings(struct net_device *ndev,
> -const struct ethtool_link_ksettings *cmd)
> -{
> - struct ravb_private *priv = netdev_priv(ndev);
> - unsigned long flags;
> - int error;
> -
> - if (!ndev->phydev)
> - return -ENODEV;
> -
> - spin_lock_irqsave(&priv->lock, flags);
> -
> - /* Disable TX and RX */
> - ravb_rcv_snd_disable(ndev);
> -
> - error = phy_ethtool_ksettings_set(ndev->phydev, cmd);
> - if (error)
> - goto error_exit;
> -
> - if (cmd->base.duplex == DUPLEX_FULL)
> - priv->duplex = 1;
> - else
> - priv->duplex = 0;
> -
> - ravb_set_duplex(ndev);
> -
> -error_exit:
> - mdelay(1);
> -
> - /* Enable TX and RX */
> - ravb_rcv_snd_enable(ndev);
> -
> - mmiowb();
> - spin_unlock_irqrestore(&priv->lock, flags);
> -
> - return error;
> -}
> -
But this part is clearly lumping it all together...
[...]
> @@ -1357,7 +1329,7 @@ static const struct ethtool_ops ravb_ethtool_ops = {
> .set_ringparam = ravb_set_ringparam,
> .get_ts_info= ravb_get_ts_info,
> .get_link_ksettings = phy_ethtool_get_link_ksettings,
> - .set_link_ksettings = ravb_set_link_ksettings,
> + .set_link_ksettings = phy_ethtool_set_link_ksettings,
Should have been a part of the final patch in the fix/enhancement chain...
> .get_wol= ravb_get_wol,
> .set_wol= ravb_set_wol,
> };
MBR, Sergei
Re: [GIT PULL] Renesas ARM Based SoC DT Bindings Updates for v4.18
On Fri, May 18, 2018 at 01:16:44PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC DT bindings updates for v4.18. > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > tags/renesas-dt-bindings-for-v4.18 > > for you to fetch changes up to c92db4a4a4c6c176c34604e456d6d355803d9ada: > > dt-bindings: arm: document Renesas V3HSK board bindings (2018-05-15 > 09:17:45 +0200) > > > Renesas ARM Based SoC DT Bindings Updates for v4.18 > > Document bindings for: > > * V3H Starter Kit, a board used with the R-Car V3H (r8a77980) SoC > * R-Car E3 (R8A77990) SoC and its Ebisu board > * iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > which uses an RZ/G1C (R8A77470) SoC > * RZ/G1M (R8A7743) and RZ/G1N (R8A7744) CMT support > > Cleanup: > * Consistently name r8a77965 as R-Car M3-N > > > Biju Das (1): > dt-bindings: arm: Document iW-RainboW-G23S single board computer > > Fabrizio Castro (1): > dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support > > Sergei Shtylyov (1): > dt-bindings: arm: document Renesas V3HSK board bindings > > Simon Horman (1): > dt-bindings: arm: consistently name r8a77965 as M3-N > > Yoshihiro Shimoda (2): > dt-bindings: arm: Document R-Car E3 SoC DT bindings > dt-bindings: arm: Document Renesas Ebisu board DT bindings > > Documentation/devicetree/bindings/arm/shmobile.txt | 10 +- > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 14 ++ > 2 files changed, 19 insertions(+), 5 deletions(-) Merged, thanks. -Olof
Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.18
On Fri, May 18, 2018 at 01:16:25PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM based SoC defconfig updates for v4.18. > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > tags/renesas-defconfig-for-v4.18 > > for you to fetch changes up to eedd7902366b17f95f4fe687c54dcfa186a53158: > > ARM: multi_v7_defconfig: Enable RENESAS_WDT (2018-05-16 11:08:35 +0200) Merged, thanks. -Olof
Re: [GIT PULL] Renesas ARM64 Based SoC DT Updates for v4.18
Hi Simon, On Fri, May 18, 2018 at 01:16:00PM +0200, Simon Horman wrote: > Hi Olof, Hi Kevin, Hi Arnd, > > Please consider these Renesas ARM64 based SoC DT updates for v4.18. > > > The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: > > Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) > > are available in the git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > tags/renesas-arm64-dt-for-v4.18 > > for you to fetch changes up to 908001d778eba06ee1d832863d4e9a1e2cfd4746: > > arm64: dts: renesas: salvator-common: Add ADV7482 support (2018-05-18 > 11:52:03 +0200) This pull request is really, really hard for us to digest. The tag description is very large, and it repeats several SoCs several times, making it hard to get an overview of what is in it. The verbosity of " says.." makes it harder on this size of a pull request as well. For example: > * Condor board with R-Car V3H (r8a77980) SoC > - Enable eMMC > > Sergei Shtylyov says "We're adding the R8A77980 MMC (SDHI) > device nodes and then enable eMMC support on the Condor board." The "Enable eMMC" line is just fine here. > > Geert Uytterhoeven (11): > arm64: dts: renesas: draak: Rename EtherAVB "mdc" pin group to "mdio" > arm64: dts: renesas: salvator-common: Rename EtherAVB "mdc" pin group > to "mdio" > arm64: dts: renesas: ulcb: Rename EtherAVB "mdc" pin group to "mdio" Why can't these be done in one commit? > arm64: dts: renesas: r8a7795: Correct whitespace > arm64: dts: renesas: r8a7796: Correct whitespace > arm64: dts: renesas: r8a77965: Correct whitespace Do these really need to be three commits to fix some whitespace? > arm64: dts: renesas: ulcb: Add BD9571 PMIC > arm64: dts: renesas: salvator-common: Add PMIC DDR Backup Power config > arm64: dts: renesas: ulcb: Add PMIC DDR Backup Power config > arm64: dts: renesas: r8a77970: Add secondary CA53 CPU core > arm64: dts: renesas: r8a77970: Add Cortex-A53 PMU node Why can't these be done in the same commit? > Kieran Bingham (7): > arm64: dts: renesas: r8a77965: Add FCPF and FCPV instances > arm64: dts: renesas: r8a77965: Add VSP instances > arm64: dts: renesas: r8a77965: Populate the DU instance placeholder > arm64: dts: renesas: r8a77965: Add HDMI encoder instance > arm64: dts: renesas: r8a77965-salvator-x: Enable DU external clocks and > HDMI > arm64: dts: renesas: r8a77965-salvator-xs: Enable DU external clocks > and HDMI These two can probably be in one commit as well. > arm64: dts: renesas: salvator-common: Add ADV7482 support > > Kuninori Morimoto (8): > arm64: dts: renesas: r8a7795: add HDMI sound support > arm64: dts: renesas: r8a7796: add HDMI sound support ... starting to see a trend? > arm64: dts: renesas: salvator-common: use audio-graph-card for Sound > arm64: dts: renesas: r8a7795-es1-salvator-x: enable HDMI sound > arm64: dts: renesas: r8a7795-salvator-xs: enable HDMI sound > arm64: dts: renesas: r8a7796-salvator-xs: enable HDMI sound > arm64: dts: renesas: r8a7795-salvator-x: enable HDMI sound > arm64: dts: renesas: r8a7796-salvator-x: enable HDMI sound ... and more. > > Magnus Damm (5): > arm64: dts: renesas: r8a77970: Update IPMMU DS1 bit number > arm64: dts: renesas: r8a7795: Enable IPMMU devices > arm64: dts: renesas: r8a7796: Enable IPMMU devices > arm64: dts: renesas: r8a77970: Enable IPMMU devices > arm64: dts: renesas: r8a77995: Enable IPMMU devices I think these 4 could be in one commit too. > > Niklas Söderlund (11): > arm64: dts: renesas: r8a7795: decrease temperature hysteresis > arm64: dts: renesas: r8a7796: decrease temperature hysteresis > arm64: dts: renesas: r8a77965: use r8a77965-sysc binding definitions > arm64: dts: renesas: r8a77965: Add R-Car Gen3 thermal support > arm64: dts: renesas: r8a77965: add I2C support > arm64: dts: renesas: r8a7795: add VIN and CSI-2 nodes > arm64: dts: renesas: r8a7795-es1: add CSI-2 node > arm64: dts: renesas: r8a7796: add VIN and CSI-2 nodes > arm64: dts: renesas: r8a77965: add VIN and CSI-2 nodes > arm64: dts: renesas: r8a77970: add VIN and CSI-2 nodes etc, etc. I'll stop here. I haven't merged this branch yet, will need to set aside more time to review the contents. I can't guarantee that it'll make v4.18 but I'll try. -Olof
Re: [GIT PULL] Renesas ARM Based SoC Updates for v4.18
On Fri, May 18, 2018 at 01:18:11PM +0200, Simon Horman wrote:
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM based SoC updates for v4.18.
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git
> tags/renesas-soc-for-v4.18
>
> for you to fetch changes up to 086b399965a7ee7e50c3b3c57f2dba30ff0334b0:
>
> soc: renesas: r8a77990-sysc: Add workaround for 3DG-{A,B} (2018-05-16
> 10:57:44 +0200)
Merged, thanks.
-Olof
