* [PATCH 2/5] gpio: pl061: rename state container struct
From: Linus Walleij @ 2016-11-25 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480068564-9447-1-git-send-email-linus.walleij@linaro.org>
The PL061 state container is named "pl061_gpio", let's rename it
to simply pl061. Less is more.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-pl061.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 8838a44351ce..b944aaefb59f 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -50,7 +50,7 @@ struct pl061_context_save_regs {
};
#endif
-struct pl061_gpio {
+struct pl061 {
spinlock_t lock;
void __iomem *base;
@@ -64,14 +64,14 @@ struct pl061_gpio {
static int pl061_get_direction(struct gpio_chip *gc, unsigned offset)
{
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
return !(readb(chip->base + GPIODIR) & BIT(offset));
}
static int pl061_direction_input(struct gpio_chip *gc, unsigned offset)
{
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
unsigned long flags;
unsigned char gpiodir;
@@ -87,7 +87,7 @@ static int pl061_direction_input(struct gpio_chip *gc, unsigned offset)
static int pl061_direction_output(struct gpio_chip *gc, unsigned offset,
int value)
{
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
unsigned long flags;
unsigned char gpiodir;
@@ -109,14 +109,14 @@ static int pl061_direction_output(struct gpio_chip *gc, unsigned offset,
static int pl061_get_value(struct gpio_chip *gc, unsigned offset)
{
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
return !!readb(chip->base + (BIT(offset + 2)));
}
static void pl061_set_value(struct gpio_chip *gc, unsigned offset, int value)
{
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
writeb(!!value << offset, chip->base + (BIT(offset + 2)));
}
@@ -124,7 +124,7 @@ static void pl061_set_value(struct gpio_chip *gc, unsigned offset, int value)
static int pl061_irq_type(struct irq_data *d, unsigned trigger)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
int offset = irqd_to_hwirq(d);
unsigned long flags;
u8 gpiois, gpioibe, gpioiev;
@@ -214,7 +214,7 @@ static void pl061_irq_handler(struct irq_desc *desc)
unsigned long pending;
int offset;
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
struct irq_chip *irqchip = irq_desc_get_chip(desc);
chained_irq_enter(irqchip, desc);
@@ -232,7 +232,7 @@ static void pl061_irq_handler(struct irq_desc *desc)
static void pl061_irq_mask(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
u8 gpioie;
@@ -245,7 +245,7 @@ static void pl061_irq_mask(struct irq_data *d)
static void pl061_irq_unmask(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
u8 gpioie;
@@ -266,7 +266,7 @@ static void pl061_irq_unmask(struct irq_data *d)
static void pl061_irq_ack(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
spin_lock(&chip->lock);
@@ -277,7 +277,7 @@ static void pl061_irq_ack(struct irq_data *d)
static int pl061_irq_set_wake(struct irq_data *d, unsigned int state)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct pl061_gpio *chip = gpiochip_get_data(gc);
+ struct pl061 *chip = gpiochip_get_data(gc);
return irq_set_irq_wake(chip->parent_irq, state);
}
@@ -295,7 +295,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
{
struct device *dev = &adev->dev;
struct pl061_platform_data *pdata = dev_get_platdata(dev);
- struct pl061_gpio *chip;
+ struct pl061 *chip;
int ret, irq, i, irq_base;
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
@@ -379,7 +379,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
#ifdef CONFIG_PM
static int pl061_suspend(struct device *dev)
{
- struct pl061_gpio *chip = dev_get_drvdata(dev);
+ struct pl061 *chip = dev_get_drvdata(dev);
int offset;
chip->csave_regs.gpio_data = 0;
@@ -400,7 +400,7 @@ static int pl061_suspend(struct device *dev)
static int pl061_resume(struct device *dev)
{
- struct pl061_gpio *chip = dev_get_drvdata(dev);
+ struct pl061 *chip = dev_get_drvdata(dev);
int offset;
for (offset = 0; offset < PL061_GPIO_NR; offset++) {
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] gpio: pl061: use local state for parent IRQ storage
From: Linus Walleij @ 2016-11-25 10:09 UTC (permalink / raw)
To: linux-arm-kernel
The driver is poking around in the struct gpio_chip internals,
which is a no-no. Use a variable in the local state container.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-pl061.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 6e3c1430616f..8838a44351ce 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -55,6 +55,7 @@ struct pl061_gpio {
void __iomem *base;
struct gpio_chip gc;
+ int parent_irq;
#ifdef CONFIG_PM
struct pl061_context_save_regs csave_regs;
@@ -276,8 +277,9 @@ static void pl061_irq_ack(struct irq_data *d)
static int pl061_irq_set_wake(struct irq_data *d, unsigned int state)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct pl061_gpio *chip = gpiochip_get_data(gc);
- return irq_set_irq_wake(gc->irq_parent, state);
+ return irq_set_irq_wake(chip->parent_irq, state);
}
static struct irq_chip pl061_irqchip = {
@@ -345,6 +347,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
dev_err(&adev->dev, "invalid IRQ\n");
return -ENODEV;
}
+ chip->parent_irq = irq;
ret = gpiochip_irqchip_add(&chip->gc, &pl061_irqchip,
irq_base, handle_bad_irq,
--
2.7.4
^ permalink raw reply related
* [PATCH 10/10] ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
From: Chen-Yu Tsai @ 2016-11-25 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-11-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Previously, the sun8i tablets used everything declared in AXP221 DTSI
> while they have an AXP223 PMIC.
>
> This corrects that so the sun8i tablets can get some features the AXP223
> has (at the moment, ability to have 100mA as maximal current on VBUS
> power supply).
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 09/10] ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
From: Chen-Yu Tsai @ 2016-11-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-10-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Previously, the Allwinner Parrot R16 used everything declared in AXP221
> DTSI while it has an AXP223 PMIC.
>
> This corrects that so the Allwinner Parrot R16 can get some features the
> AXP223 has (at the moment, ability to have 100mA as maximal current on
> VBUS power supply).
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 08/10] ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
From: Chen-Yu Tsai @ 2016-11-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-9-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Previously, the Sinlinx SinA33 used everything declared in AXP221 DTSI
> while it has an AXP223 PMIC.
>
> This corrects that so the Sinlinx SinA33 can get some features the
> AXP223 has (at the moment, ability to have 100mA as maximal current on
> VBUS power supply).
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 07/10] ARM: dts: sun8i-a33-olinuxino: use AXP223 DTSI
From: Chen-Yu Tsai @ 2016-11-25 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-8-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Previously, the Olimex A33-OlinuXino used everything declared in AXP221
> DTSI while it has an AXP223 PMIC.
>
> This corrects that so the Olimex A33-OlinuXino can get some features the
> AXP223 has (at the moment, ability to have 100mA as maximal current on
> VBUS power supply).
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 06/10] ARM: dtsi: add DTSI for AXP223
From: Chen-Yu Tsai @ 2016-11-25 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-7-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> The AXP223 shares most of its logic with the AXP221 but it has some
> differences for the VBUS driver.
You could also mention this in the dtsi file itself.
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> arch/arm/boot/dts/axp223.dtsi | 55 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 arch/arm/boot/dts/axp223.dtsi
>
> diff --git a/arch/arm/boot/dts/axp223.dtsi b/arch/arm/boot/dts/axp223.dtsi
> new file mode 100644
> index 0000000..f8ce55c
> --- /dev/null
> +++ b/arch/arm/boot/dts/axp223.dtsi
> @@ -0,0 +1,55 @@
> +/*
> + * Copyright 2016 Free Electrons
> + *
> + * Quentin Schulz <quentin.schulz@free-electrons.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/*
> + * AXP223 Integrated Power Management Chip
> + * http://www.x-powers.com/product/AXP22X.php
> + * http://dl.linux-sunxi.org/AXP/AXP223-en.pdf
> + */
> +
> +#include "axp22x.dtsi"
> +
> +&usb_power_supply {
> + compatible = "x-powers,axp223-usb-power-supply";
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 05/10] mfd: axp20x: add separate MFD cell for AXP223
From: Chen-Yu Tsai @ 2016-11-25 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-6-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> The AXP223 shares most of its logic with the AXP221 but has some
> differences for the VBUS power supply driver. Thus, to probe the driver
> with the correct compatible, the AXP221 and the AXP223 now have separate
> MFD cells.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/mfd/axp20x.c | 22 +++++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..989d568 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -602,6 +602,21 @@ static struct mfd_cell axp22x_cells[] = {
> },
> };
>
> +static struct mfd_cell axp223_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp22x_pek_resources),
> + .resources = axp22x_pek_resources,
> + }, {
> + .name = "axp20x-regulator",
> + }, {
> + .name = "axp20x-usb-power-supply",
> + .of_compatible = "x-powers,axp223-usb-power-supply",
> + .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> + .resources = axp22x_usb_power_supply_resources,
Nit: Please align the statements. And you might want to rename the original
axp22x_cells to axp221_cells to avoid confusion. Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + },
> +};
> +
> static struct mfd_cell axp152_cells[] = {
> {
> .name = "axp20x-pek",
> @@ -789,12 +804,17 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
> break;
> case AXP221_ID:
> - case AXP223_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
> axp20x->cells = axp22x_cells;
> axp20x->regmap_cfg = &axp22x_regmap_config;
> axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
> break;
> + case AXP223_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp223_cells);
> + axp20x->cells = axp223_cells;
> + axp20x->regmap_cfg = &axp22x_regmap_config;
> + axp20x->regmap_irq_chip = &axp22x_regmap_irq_chip;
> + break;
> case AXP288_ID:
> axp20x->cells = axp288_cells;
> axp20x->nr_cells = ARRAY_SIZE(axp288_cells);
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH] mtd: nand: mxc: Fix mxc_v1 ooblayout
From: Marek Vasut @ 2016-11-25 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480065209-4179-1-git-send-email-boris.brezillon@free-electrons.com>
On 11/25/2016 10:13 AM, Boris Brezillon wrote:
> Commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> introduced a bug in the OOB layout description. Even if the driver claims
> that 3 ECC bytes are reserved to protect 512 bytes of data, it's actually
> 5 ECC bytes to protect 512+6 bytes of data (some OOB bytes are also
> protected using extra ECC bytes).
>
> Fix the mxc_v1_ooblayout_{free,ecc}() functions to reflect this behavior.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> Fixes: a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> Cc: <stable@vger.kernel.org>
> ---
> drivers/mtd/nand/mxc_nand.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> index 61ca020c5272..c19ec4f0983e 100644
> --- a/drivers/mtd/nand/mxc_nand.c
> +++ b/drivers/mtd/nand/mxc_nand.c
> @@ -886,7 +886,7 @@ static int mxc_v1_ooblayout_ecc(struct mtd_info *mtd, int section,
> return -ERANGE;
>
> oobregion->offset = (section * 16) + 6;
> - oobregion->length = nand_chip->ecc.bytes;
> + oobregion->length = 5;
Use a macro instead of hard-coding a value please :)
> return 0;
> }
> @@ -908,8 +908,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
> oobregion->length = 4;
> }
> } else {
> - oobregion->offset = ((section - 1) * 16) +
> - nand_chip->ecc.bytes + 6;
> + oobregion->offset = ((section - 1) * 16) + 5 + 6;
DTTO here, the math here is cryptic enough.
> if (section < nand_chip->ecc.steps)
> oobregion->length = (section * 16) + 6 -
> oobregion->offset;
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 04/10] power: supply: axp20x_usb_power: add 100mA max current limit for AXP223
From: Chen-Yu Tsai @ 2016-11-25 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-5-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> The X-Powers AXP223 shares most of its behaviour with the AXP221 PMIC
> but allows the VBUS power supply max current to be set to 100mA (like
> the AXP209 PMIC).
>
> This basically adds a new compatible to the VBUS power supply driver and
> adds a check on the compatible when setting current max limit.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
From: Jerome Brunet @ 2016-11-25 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCCg8cLuQdrRsxHA53JAvyWgfW7vfVMho0tj3bCCcu-YxA@mail.gmail.com>
On Thu, 2016-11-24 at 18:10 +0100, Martin Blumenstingl wrote:
> On Thu, Nov 24, 2016 at 5:01 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > On Thu, 2016-11-24 at 15:40 +0100, Martin Blumenstingl wrote:
> > >
> > > Hi Jerome,
> > >
> > > On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet@baylibre.
> > > com>
> > > wrote:
> > > >
> > > >
> > > > This patchset fixes an issue with the OdroidC2 board (DWMAC +
> > > > RTL8211F).
> > > > Initially reported as a low Tx throughput issue at gigabit
> > > > speed,
> > > > the
> > > > platform enters LPI too often. This eventually break the link
> > > > (both
> > > > Tx
> > > > and Rx), and require to bring the interface down and up again
> > > > to
> > > > get the
> > > > Rx path working again.
> > > >
> > > > The root cause of this issue is not fully understood yet but
> > > > disabling EEE
> > > > advertisement on the PHY prevent this feature to be negotiated.
> > > > With this change, the link is stable and reliable, with the
> > > > expected
> > > > throughput performance.
> > > I have just sent a series which allows configuring the TX delay
> > > on
> > > the
> > > MAC (dwmac-meson8b glue) side: [0]
> > > Disabling the TX delay generated by the MAC fixes TX throughput
> > > for
> > > me, even when leaving EEE enabled in the RTL8211F PHY driver!
> > >
> > > Unfortunately the RTL8211F PHY is a black-box for the community
> > > because there is no public datasheeet available.
> > > *maybe* (pure speculation!) they're enabling the TX delay based
> > > on
> > > some internal magic only when EEE is enabled.
> >
> > Hi already tried acting on the register setting the TX_delay. I
> > also
> > tried on the PHY. I never been able to improve situation on the
> > Odroic2. Only disabling EEE improved the situation.
> OK, thanks for clarifying this!
>
> >
> > To make sure, i tried again with your patch but the result remains
> > unchanged. With Tx_delay disabled (either the mac or the phy), the
> > situation is even worse, it seems that nothing gets through
> This is interesting, because in your case you should have a 4ns TX
> delay (2ns from the MAC and presumably 2ns from the PHY).
> Maybe that is also the reason why the TX delay is configurable in 2ns
> steps in PRG_ETHERNET0 on Amlogic SoCs.
>
> out of curiosity: have you tried setting a 4ns (half clock-cycle) TX
> delay for the MAC and disabling it in the PHY?
Just replied on the other thread. Long story short, Odroidc2 seems to
really require EEE to be switched off.
Again, thx for your help Martin
>
>
> Regards,
> Martin
^ permalink raw reply
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Jerome Brunet @ 2016-11-25 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCB7sXjXor++W+PW0-j_VxATRzhexjqHgXj2jD10tBpZFg@mail.gmail.com>
On Thu, 2016-11-24 at 18:05 +0100, Martin Blumenstingl wrote:
> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com>
> wrote:
> >
> > On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
> > >
> > > Currently the dwmac-meson8b stmmac glue driver uses a hardcoded
> > > 1/4
> > > cycle TX clock delay. This seems to work fine for many boards
> > > (for
> > > example Odroid-C2 or Amlogic's reference boards) but there are
> > > some
> > > others where TX traffic is simply broken.
> > > There are probably multiple reasons why it's working on some
> > > boards
> > > while it's broken on others:
> > > - some of Amlogic's reference boards are using a Micrel PHY
> > > - hardware circuit design
> > > - maybe more...
> > >
> > > This raises a question though:
> > > Which device is supposed to enable the TX delay when both MAC and
> > > PHY
> > > support it? And should we implement it for each PHY / MAC
> > > separately
> > > or should we think about a more generic solution (currently it's
> > > not
> > > possible to disable the TX delay generated by the RTL8211F PHY
> > > via
> > > devicetree when using phy-mode "rgmii")?
> >
> > Actually you can skip the part which activate the Tx-delay on the
> > phy
> > by setting "phy-mode = "rgmii-id" instead of "rgmii"
> >
> > phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
> > but PHY_INTERFACE_MODE_RGMII_ID.
> unfortunately this is not true for RTL8211F (I did my previous tests
> with the same expectation in mind)!
> the code seems to suggest that TX-delay is disabled whenever mode !=
> PHY_INTERFACE_MODE_RGMII.
> BUT: on my device RTL8211F_TX_DELAY is set even before
> "phy_write(phydev, 0x11, reg);"!
Thx a lot for pointing this out. I wrongly assumed that is was off by
default. It turns out it is ON on the OdroidC2 as well.
So I re-did all my test:
On the OdroidC2, as long as eee is not disabled (using ethtool or
through my patch) I can't get iperf to work properly. Disabling EEE,
the link works for the following configurations:
PHY TX Delay bit set : MAC delay 0ns, 2ns.
PHY TX Delay bit cleared : MAC delay 2ns, 4ns.
This seems to confirm that the PHY adds a 2ns delay when the bit is
set.
I could not test on my MXQPRO2.1 ... the PHY is no longer found during
the boot. Something died overnight :(?
>
> Based on what I found it seems that rgmii-id, rgmii-txid and
> rgmii-rxid are supposed to be handled by the PHY.
> That would mean that we have two problems here:
> 1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
> PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
> enable the TX-delay in that case - otherwise explicitly disable it
> 2) dwmac-meson8b.c should only use the configured TX-delay for
> PHY_INTERFACE_MODE_RGMII
> @Florian: could you please share your thoughts on this (who handles
> the TX delay in which case)?
>
>
> Regards,
> Martin
^ permalink raw reply
* [GIT PULL] ARM64: berlin: DT changes for v4.10
From: Jisheng Zhang @ 2016-11-25 9:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the first time I send pull request for berlin SoC. This is a PR for
the Berlin64 DT changes for v4.10. Please pull.
Thanks,
Jisheng
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin.git tags/berlin64-dt-for-v4.10-1
for you to fetch changes up to 40fdc6b0d2b96cac46be51eb41042a715047b791:
arm64: dts: berlin4ct-dmp: add missing unit name to /memory node (2016-11-25 17:14:00 +0800)
----------------------------------------------------------------
Berlin64 DT changes for v4.10
- fix some dtc compiler warnings
----------------------------------------------------------------
Jisheng Zhang (3):
arm64: dts: berlin4ct: add missing unit name to /soc node
arm64: dts: berlin4ct-stb: add missing unit name to /memory node
arm64: dts: berlin4ct-dmp: add missing unit name to /memory node
arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts | 2 +-
arch/arm64/boot/dts/marvell/berlin4ct-stb.dts | 2 +-
arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: Ard Biesheuvel @ 2016-11-25 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15173.1480066220@warthog.procyon.org.uk>
On 25 November 2016 at 09:30, David Howells <dhowells@redhat.com> wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
>> Since you seem to be using this to mean "is the platform locked down?",
>> this looks to be no longer complete in the UEFI 2.6 world. If
>> DeployedMode == 0, even if SecureBoot == 1 and SetupMode == 0, you can
>> remove the platform key by writing 1 to AuditMode and gain control of
>> the secure variables. The lock down state becomes DeployedMode == 1,
>> SecureBoot == 1 and SetupMode == 0
>>
>> See the diagram on page 1817
>>
>> http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
>
> How many pages?!
>
> Does the DeployedMode variable not exist in older versions of the UEFI spec?
>
No, it was added in 2.6
^ permalink raw reply
* [GIT PULL] ARM: berlin: DT changes for v4.10
From: Jisheng Zhang @ 2016-11-25 9:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the first time I send pull request for berlin SoC. This is a PR for
the Berlin DT changes for v4.10. Please pull.
Thanks,
Jisheng
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jszhang/linux-berlin.git tags/berlin-dt-for-v4.10-1
for you to fetch changes up to 0248994d7cce890e9bb75a8ee2d41016c990a7fd:
ARM: dts: berlin2q-marvell-dmp: fix typo in chosen node (2016-11-25 16:52:18 +0800)
----------------------------------------------------------------
Berlin DT changes for v4.10
- fix DTC compiler warning
- fix typo in chosen node
----------------------------------------------------------------
Jisheng Zhang (1):
ARM: dts: berlin2q-marvell-dmp: fix regulators' name
Masahiro Yamada (1):
ARM: dts: berlin2q-marvell-dmp: fix typo in chosen node
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 02/10] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Thomas Petazzoni @ 2016-11-25 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-3-quentin.schulz@free-electrons.com>
Quentin,
On Fri, 25 Nov 2016 10:09:13 +0100, Quentin Schulz wrote:
> +static int axp20x_usb_power_set_property(struct power_supply *psy,
> + enum power_supply_property psp,
> + const union power_supply_propval *val)
> +{
> + struct axp20x_usb_power *power = power_supply_get_drvdata(psy);
> + int ret, val1;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_VOLTAGE_MIN:
> + switch (val->intval) {
This nested switch construct doesn't look very pretty. What about
instead:
switch(psp) {
case POWER_SUPPLY_PROP_VOLTAGE_MIN:
return axp20x_usb_power_set_prop_voltage_min(...);
case POWER_SUPPLY_PROP_CURRENT_MAX:
return axp20x_usb_power_set_prop_current_max(...);
default:
return -EINVAL;
}
> + case 4000000:
> + case 4100000:
> + case 4200000:
> + case 4300000:
> + case 4400000:
> + case 4500000:
> + case 4600000:
> + case 4700000:
> + val1 = (val->intval - 4000000) / 100000;
> + ret = regmap_update_bits(power->regmap,
> + AXP20X_VBUS_IPSOUT_MGMT,
> + AXP20X_VBUS_VHOLD_MASK,
> + val1 << 3);
> + if (ret)
> + return ret;
> +
> + return 0;
Just do:
return regmap_update_bits(...);
The dance to test ret is useless, since you anyway return ret when
non-zero, or return zero when ret was zero.
While you're at it, maybe make val1 a u32, since I guess it's written
to a 32-bit register (unless u32 is not commonly used in this driver
already, of course).
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 02/10] power: supply: axp20x_usb_power: set min voltage and max current from sysfs
From: Chen-Yu Tsai @ 2016-11-25 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-3-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> AXP20X and AXP22X PMICs allow setting the min voltage and max current of
> VBUS power supply. This adds entries in sysfs to allow to do so.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/power/supply/axp20x_usb_power.c | 72 +++++++++++++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 3 ++
> 2 files changed, 75 insertions(+)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
> index b19754e..638cb52 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -155,6 +155,74 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
> return 0;
> }
>
> +static int axp20x_usb_power_set_property(struct power_supply *psy,
> + enum power_supply_property psp,
> + const union power_supply_propval *val)
> +{
> + struct axp20x_usb_power *power = power_supply_get_drvdata(psy);
> + int ret, val1;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_VOLTAGE_MIN:
> + switch (val->intval) {
> + case 4000000:
> + case 4100000:
> + case 4200000:
> + case 4300000:
> + case 4400000:
> + case 4500000:
> + case 4600000:
> + case 4700000:
> + val1 = (val->intval - 4000000) / 100000;
> + ret = regmap_update_bits(power->regmap,
> + AXP20X_VBUS_IPSOUT_MGMT,
> + AXP20X_VBUS_VHOLD_MASK,
> + val1 << 3);
Please also define the shift offset.
> + if (ret)
> + return ret;
> +
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +
> + case POWER_SUPPLY_PROP_CURRENT_MAX:
> + switch (val->intval) {
> + case 100000:
> + if (power->axp20x_id == AXP221_ID)
> + return -EINVAL;
> + case 500000:
> + case 900000:
> + val1 = (900000 - val->intval) / 400000;
> + ret = regmap_update_bits(power->regmap,
> + AXP20X_VBUS_IPSOUT_MGMT,
> + AXP20X_VBUS_CLIMIT_MASK, val1);
> + if (ret)
> + return ret;
> +
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int axp20x_usb_power_prop_writeable(struct power_supply *psy,
> + enum power_supply_property psp)
> +{
> + return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN ||
> + psp == POWER_SUPPLY_PROP_CURRENT_MAX;
> +}
> +
> static enum power_supply_property axp20x_usb_power_properties[] = {
> POWER_SUPPLY_PROP_HEALTH,
> POWER_SUPPLY_PROP_PRESENT,
> @@ -178,7 +246,9 @@ static const struct power_supply_desc axp20x_usb_power_desc = {
> .type = POWER_SUPPLY_TYPE_USB,
> .properties = axp20x_usb_power_properties,
> .num_properties = ARRAY_SIZE(axp20x_usb_power_properties),
> + .property_is_writeable = axp20x_usb_power_prop_writeable,
> .get_property = axp20x_usb_power_get_property,
> + .set_property = axp20x_usb_power_set_property,
> };
>
> static const struct power_supply_desc axp22x_usb_power_desc = {
> @@ -186,7 +256,9 @@ static const struct power_supply_desc axp22x_usb_power_desc = {
> .type = POWER_SUPPLY_TYPE_USB,
> .properties = axp22x_usb_power_properties,
> .num_properties = ARRAY_SIZE(axp22x_usb_power_properties),
> + .property_is_writeable = axp20x_usb_power_prop_writeable,
> .get_property = axp20x_usb_power_get_property,
> + .set_property = axp20x_usb_power_set_property,
> };
>
> static const struct of_device_id axp20x_usb_power_match[] = {
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index fec597f..8883595 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -56,6 +56,9 @@ enum {
> #define AXP20X_LDO24_V_OUT 0x28
> #define AXP20X_LDO3_V_OUT 0x29
> #define AXP20X_VBUS_IPSOUT_MGMT 0x30
> +
> +#define AXP20X_VBUS_VHOLD_MASK GENMASK(5, 3)
> +
For the AXP drivers, we keep the per register bit field
definitions in the drivers that use them.
Regards
ChenYu
> #define AXP20X_V_OFF 0x31
> #define AXP20X_OFF_CTRL 0x32
> #define AXP20X_CHRG_CTRL1 0x33
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes
From: Icenowy Zheng @ 2016-11-25 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cdf50b8433e2d9a053e35f8788bfcd5d41504312.1479641523.git.moinejf@free.fr>
20.11.2016, 20:12, "Jean-Francois Moine" <moinejf@free.fr>:
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> ?arch/arm/boot/dts/sun8i-h3.dtsi | 51 +++++++++++++++++++++++++++++++++++++++++
> ?1 file changed, 51 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 416b825..7c6b1d5 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -140,6 +140,16 @@
> ?????????????????#size-cells = <1>;
> ?????????????????ranges;
>
> + de: de-controller at 01000000 {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + reg = <0x01000000 0x400000>;
> + clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>;
> + clock-names = "bus", "clock";
> + resets = <&ccu RST_BUS_DE>;
> + ports = <&lcd0_p>;
> + status = "disabled";
> + };
> +
> ?????????????????dma: dma-controller at 01c02000 {
> ?????????????????????????compatible = "allwinner,sun8i-h3-dma";
> ?????????????????????????reg = <0x01c02000 0x1000>;
> @@ -149,6 +159,23 @@
> ?????????????????????????#dma-cells = <1>;
> ?????????????????};
>
> + lcd0: lcd-controller at 01c0c000 {
> + compatible = "allwinner,sun8i-a83t-tcon";
> + reg = <0x01c0c000 0x400>;
> + clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
> + clock-names = "bus", "clock";
> + resets = <&ccu RST_BUS_TCON0>;
> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcd0_p: port {
> + lcd0_hdmi: endpoint {
> + remote-endpoint = <&hdmi_lcd0>;
> + };
> + };
> + };
> +
> ?????????????????mmc0: mmc at 01c0f000 {
> ?????????????????????????compatible = "allwinner,sun7i-a20-mmc";
> ?????????????????????????reg = <0x01c0f000 0x1000>;
> @@ -314,6 +341,11 @@
> ?????????????????????????clock-names = "hosc", "losc";
> ?????????????????????????#clock-cells = <1>;
> ?????????????????????????#reset-cells = <1>;
> +
> + assigned-clocks = <&ccu CLK_PLL_DE>,
> + <&ccu CLK_DE>;
> + assigned-clock-rates = <864000000>,
> + <432000000>;
> ?????????????????};
>
> ?????????????????pio: pinctrl at 01c20800 {
> @@ -564,6 +596,25 @@
> ?????????????????????????interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> ?????????????????};
>
> + hdmi: hdmi at 01ee0000 {
> + compatible = "allwinner,sun8i-h3-hdmi";
> + reg = <0x01ee0000 0x20000>;
> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
> + <&ccu CLK_HDMI_DDC>;
> + clock-names = "bus", "clock", "ddc-clock";
> + resets = <&ccu RST_BUS_HDMI0>, <&ccu RST_BUS_HDMI1>;
> + reset-names = "hdmi0", "hdmi1";
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port at 0 { /* video */
> + reg = <0>;
> + hdmi_lcd0: endpoint {
> + remote-endpoint = <&lcd0_hdmi>;
> + };
> + };
> + };
> +
> ?????????????????rtc: rtc at 01f00000 {
> ?????????????????????????compatible = "allwinner,sun6i-a31-rtc";
> ?????????????????????????reg = <0x01f00000 0x54>;
After removing CLK_PLL_DE's assigned-clock, the kernel passes compilation.
However, it cannot recognize any HDMI screen...
(My board is Orange Pi One, and I manually added status="okay"; to &lcd0, &de, &hdmi)
[ 16.507802] sun8i-de2 1000000.de-controller: bound 1c0c000.lcd-controller (ops de2_lcd_ops [sun8i_de2_drm])
[ 16.675948] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops de2_hdmi_fini [sun8i_de2_hdmi])
[ 16.685120] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 16.695876] [drm] No driver support for vblank timestamp query.
[ 16.701862] sun8i-de2 1000000.de-controller: No connectors reported connected with modes
[ 16.713061] [drm] Cannot find any crtc or sizes - going 1024x768
[ 16.734214] Console: switching to colour frame buffer device 128x48
[ 16.751022] sun8i-de2 1000000.de-controller: fb0: frame buffer device
> --
> 2.10.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 5/7] efi: Get the secure boot status [ver #3]
From: David Howells @ 2016-11-25 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480016487.2444.18.camel@HansenPartnership.com>
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> Since you seem to be using this to mean "is the platform locked down?",
> this looks to be no longer complete in the UEFI 2.6 world. If
> DeployedMode == 0, even if SecureBoot == 1 and SetupMode == 0, you can
> remove the platform key by writing 1 to AuditMode and gain control of
> the secure variables. The lock down state becomes DeployedMode == 1,
> SecureBoot == 1 and SetupMode == 0
>
> See the diagram on page 1817
>
> http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf
How many pages?!
Does the DeployedMode variable not exist in older versions of the UEFI spec?
David
^ permalink raw reply
* [PATCH 03/10] Documentation: DT: binding: axp20x_usb_power: add axp223 compatible
From: Chen-Yu Tsai @ 2016-11-25 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-4-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This adds the "x-powers,axp223-usb-power-supply" to the list of
> compatibles for AXP20X VBUS power supply driver.
Please explain why we need this. Basically the part about
AXP221 vs AXP223 from your cover letter.
ChenYu
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index f1d7bee..bf3953c 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -3,6 +3,7 @@ AXP20x USB power supply
> Required Properties:
> -compatible: One of: "x-powers,axp202-usb-power-supply"
> "x-powers,axp221-usb-power-supply"
> + "x-powers,axp223-usb-power-supply"
>
> This node is a subnode of the axp20x PMIC.
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH] dt-bindings: clarify compatible field usage for rockchip timers
From: Alexander Kochetkov @ 2016-11-25 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480025455-6797-1-git-send-email-al.kochet@gmail.com>
Hello,
Here the thread where the patch was discussed:
http://lists.infradead.org/pipermail/linux-rockchip/2016-November/013174.html
Regards,
Alexander.
^ permalink raw reply
* [PATCH 01/10] power: supply: axp20x_usb_power: use of_device_id data field instead of device_is_compatible
From: Chen-Yu Tsai @ 2016-11-25 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125090921.23138-2-quentin.schulz@free-electrons.com>
On Fri, Nov 25, 2016 at 5:09 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> This replaces calls to of_device_is_compatible to check data field of
> of_device_id matched when probing the driver.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> drivers/power/supply/axp20x_usb_power.c | 39 ++++++++++++++++++++-------------
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
> index 6af6feb..b19754e 100644
> --- a/drivers/power/supply/axp20x_usb_power.c
> +++ b/drivers/power/supply/axp20x_usb_power.c
> @@ -17,6 +17,7 @@
> #include <linux/mfd/axp20x.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/platform_device.h>
> #include <linux/power_supply.h>
> #include <linux/regmap.h>
> @@ -45,6 +46,7 @@ struct axp20x_usb_power {
> struct device_node *np;
> struct regmap *regmap;
> struct power_supply *supply;
> + int axp20x_id;
> };
>
> static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
> @@ -86,8 +88,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
>
> switch (v & AXP20X_VBUS_CLIMIT_MASK) {
> case AXP20X_VBUC_CLIMIT_100mA:
> - if (of_device_is_compatible(power->np,
> - "x-powers,axp202-usb-power-supply")) {
> + if (power->axp20x_id == AXP202_ID) {
> val->intval = 100000;
> } else {
> val->intval = -1; /* No 100mA limit */
> @@ -130,8 +131,7 @@ static int axp20x_usb_power_get_property(struct power_supply *psy,
>
> val->intval = POWER_SUPPLY_HEALTH_GOOD;
>
> - if (of_device_is_compatible(power->np,
> - "x-powers,axp202-usb-power-supply")) {
> + if (power->axp20x_id == AXP202_ID) {
> ret = regmap_read(power->regmap,
> AXP20X_USB_OTG_STATUS, &v);
> if (ret)
> @@ -189,6 +189,17 @@ static const struct power_supply_desc axp22x_usb_power_desc = {
> .get_property = axp20x_usb_power_get_property,
> };
>
> +static const struct of_device_id axp20x_usb_power_match[] = {
> + {
> + .compatible = "x-powers,axp202-usb-power-supply",
> + .data = (void *)AXP202_ID,
> + }, {
> + .compatible = "x-powers,axp221-usb-power-supply",
> + .data = (void *)AXP221_ID,
> + }, { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
> +
There's no need to move this. See why below.
> static int axp20x_usb_power_probe(struct platform_device *pdev)
> {
> struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> @@ -200,11 +211,16 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
> "VBUS_PLUGIN", "VBUS_REMOVAL", NULL };
> static const char * const *irq_names;
> const struct power_supply_desc *usb_power_desc;
> + const struct of_device_id *of_id;
> int i, irq, ret;
>
> if (!of_device_is_available(pdev->dev.of_node))
> return -ENODEV;
>
> + of_id = of_match_device(axp20x_usb_power_match, &pdev->dev);
> + if (!of_id)
> + return -ENODEV;
> +
You can use of_device_get_match_data() instead.
ChenYu
> if (!axp20x) {
> dev_err(&pdev->dev, "Parent drvdata not set\n");
> return -EINVAL;
> @@ -214,11 +230,12 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
> if (!power)
> return -ENOMEM;
>
> + power->axp20x_id = (int)of_id->data;
> +
> power->np = pdev->dev.of_node;
> power->regmap = axp20x->regmap;
>
> - if (of_device_is_compatible(power->np,
> - "x-powers,axp202-usb-power-supply")) {
> + if (power->axp20x_id == AXP202_ID) {
> /* Enable vbus valid checking */
> ret = regmap_update_bits(power->regmap, AXP20X_VBUS_MON,
> AXP20X_VBUS_MON_VBUS_VALID,
> @@ -235,8 +252,7 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
>
> usb_power_desc = &axp20x_usb_power_desc;
> irq_names = axp20x_irq_names;
> - } else if (of_device_is_compatible(power->np,
> - "x-powers,axp221-usb-power-supply")) {
> + } else if (power->axp20x_id == AXP221_ID) {
> usb_power_desc = &axp22x_usb_power_desc;
> irq_names = axp22x_irq_names;
> } else {
> @@ -272,13 +288,6 @@ static int axp20x_usb_power_probe(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct of_device_id axp20x_usb_power_match[] = {
> - { .compatible = "x-powers,axp202-usb-power-supply" },
> - { .compatible = "x-powers,axp221-usb-power-supply" },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
> -
> static struct platform_driver axp20x_usb_power_driver = {
> .probe = axp20x_usb_power_probe,
> .driver = {
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 7/9] clocksource/drivers/rockchip_timer: implement clocksource timer
From: Alexander Kochetkov @ 2016-11-25 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1800621.EhepfMxccR@diego>
Hello Heiko!
> 24 ????. 2016 ?., ? 15:17, Heiko St?bner <heiko@sntech.de> ???????(?):
>
> When touching devicetree-properties, please also adapt the binding document
> Documentation/devicetree/bindings/timer,rockchip,rk-timer.txt
> in this case and also include the devicetree maintainers.
Could you please clarify, i should send whole patch series and include devicetree maintainers
for whole patch series or i should send devicetree patches separately?
> 24 ????. 2016 ?., ? 16:21, Heiko St?bner <heiko@sntech.de> ???????(?):
>
> correct, use both but also update the binding, like
> mmc/rockchip-dw-mshc.txt does.
Here devicetree patch for this:
http://www.spinics.net/lists/devicetree/msg152246.html
> 24 ????. 2016 ?., ? 17:32, Heiko St?bner <heiko@sntech.de> ???????(?):
>
>> I may suggest such solution here: if I want clocksource, I have to declare
>> two timer in device tree. First probed timer would be clockevent and second
>> one would be clocksource. All other timers will be ignored. Is that
>> solution good?
>
> yep, sounds good, especially as with your patch 9/9 you already declare these
> necessary timers.
>
>> If I want one timer and want it be clocksource not clockevent how that
>> situation should be configured? Device tree not good for this. Kconfig not
>> good. Pass that configuration on kernel command line?
>
> simply ignore that case :-)
Here devicetree patch for this:
http://www.spinics.net/lists/devicetree/msg152247.html
And I?ll going to resend new patch series with discussed modifications.
It will contain only rk_timer and dts modifications.
I have to do more tests.
Regards,
Alexander.
^ permalink raw reply
* [PATCH] mtd: nand: mxc: Fix mxc_v1 ooblayout
From: Boris Brezillon @ 2016-11-25 9:13 UTC (permalink / raw)
To: linux-arm-kernel
Commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
introduced a bug in the OOB layout description. Even if the driver claims
that 3 ECC bytes are reserved to protect 512 bytes of data, it's actually
5 ECC bytes to protect 512+6 bytes of data (some OOB bytes are also
protected using extra ECC bytes).
Fix the mxc_v1_ooblayout_{free,ecc}() functions to reflect this behavior.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
Cc: <stable@vger.kernel.org>
---
drivers/mtd/nand/mxc_nand.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 61ca020c5272..c19ec4f0983e 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -886,7 +886,7 @@ static int mxc_v1_ooblayout_ecc(struct mtd_info *mtd, int section,
return -ERANGE;
oobregion->offset = (section * 16) + 6;
- oobregion->length = nand_chip->ecc.bytes;
+ oobregion->length = 5;
return 0;
}
@@ -908,8 +908,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
oobregion->length = 4;
}
} else {
- oobregion->offset = ((section - 1) * 16) +
- nand_chip->ecc.bytes + 6;
+ oobregion->offset = ((section - 1) * 16) + 5 + 6;
if (section < nand_chip->ecc.steps)
oobregion->length = (section * 16) + 6 -
oobregion->offset;
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: davinci_all_defconfig: enable dumb vga-dac drm bridge
From: Bartosz Golaszewski @ 2016-11-25 9:13 UTC (permalink / raw)
To: linux-arm-kernel
This enables the dumb-vga-dac driver by default for davinci boards.
The driver is needed for tilcdc support on da850-lcdk board.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..ab1bf18 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -127,6 +127,8 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_DRM=m
CONFIG_DRM_TILCDC=m
+CONFIG_DRM_BRIDGE=y
+CONFIG_DRM_DUMB_VGA_DAC=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DA8XX=y
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox