* [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes
From: Icenowy Zheng @ 2016-11-25 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125112213.83420594eb435b6bb1a4d164@free.fr>
25.11.2016, 18:22, "Jean-Francois Moine" <moinejf@free.fr>:
> On Fri, 25 Nov 2016 17:41:51 +0800
> Icenowy Zheng <icenowy@aosc.xyz> wrote:
>
>> ?After removing CLK_PLL_DE's assigned-clock, the kernel passes compilation.
>
> The 'pll-de' and 'de' must have a fixed rate. Otherwise, if you do not
> use the legacy u-boot, I don't know which can be the rate of the DE.
Can't CCU deal with this?
I still kept the CLK_DE's assigned-clock...
>
>> ?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
>
> I put a 'pr_warn' message is case the EDID cannot be read.
> Have you this message?
Seems no...
>
> Anyway, there is a problem with the EDID:
> - my Orange Pi 2 (H3) randomly fails to read it. But this succeeds after
> ??rebooting once or twice.
> - my Banana Pi M2+ (H3) reads it correctly each time.
> - my Banana Pi M3 (A83T) can never read it.
>
> BTW, on first tries, I was forcing a CEA mode thru the kernel command
> line. This was working with the OPi2 and BPiM3, but there was no sound.
> In the last version, I use a EDID in edid_firmware for having sound
> with the BPiM3. This works fine.
> But, forcing a CEA mode is no more possible, so, when the OPi2 cannot
> read the EDID, the system switches to a VGA mode (default 1024x768)
> which is not supported. It seems that this is your case.
>
> So, in brief, if your board cannot read the EDID, put a EDID somewhere
> and its path in /sys/module/drm_kms_helper/parameters/edid_firmware.
> There will be no console, but X11 will work correctly.
The problem seems to be that the CRTC is not properly initialized...
>
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
^ permalink raw reply
* [RFC v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-11-25 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01de97d9-e910-d9f3-f081-215a78f7f4d2@linaro.org>
Am Freitag, den 25.11.2016, 11:04 +0800 schrieb zhangfei:
>
> On 2016?11?24? 17:26, Philipp Zabel wrote:
> > Am Mittwoch, den 23.11.2016, 16:07 +0800 schrieb Zhangfei Gao:
> >> Add DT bindings documentation for hi3660 SoC reset controller.
> >>
> >> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> >> ---
> >> .../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++++++++++++++++
> >> 1 file changed, 51 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >> new file mode 100644
> >> index 0000000..250daf2
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >> @@ -0,0 +1,51 @@
> >> +Hisilicon System Reset Controller
> >> +======================================
> >> +
> >> +Please also refer to reset.txt in this directory for common reset
> >> +controller binding usage.
> >> +
> >> +The reset controller registers are part of the system-ctl block on
> >> +hi3660 SoC.
> >> +
> >> +Required properties:
> >> +- compatible: should be
> >> + "hisilicon,hi3660-reset"
> >> +- #reset-cells: 1, see below
> >> +- hisi,rst-syscon: phandle of the reset's syscon.
> >> +- hisi,reset-bits: Contains the reset control register information
> >> + Should contain 2 cells for each reset exposed to
> >> + consumers, defined as:
> >> + Cell #1 : offset from the syscon register base
> >> + Cell #2 : bits position of the control register
> >> +
> >> +Example:
> >> + iomcu: iomcu at ffd7e000 {
> >> + compatible = "hisilicon,hi3660-iomcu", "syscon";
> >> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> >> + };
> >> +
> >> + iomcu_rst: iomcu_rst_controller {
> > This should be
> > iomcu_rst: reset-controller {
> By the way, could I keep the original name?
> Since there will be build error if several nodes use the same name.
> like:
> - iomcu_rst: iomcu_rst_controller {
> + iomcu_rst: reset-controller {
>
> - crg_rst: crg_rst_controller {
> + crg_rst: reset-controller {
That should not be a problem if they are moved inside the controlling
node:
iomcu {
iomcu_rst: reset-controller {
};
};
crg {
crg_rst: reset-controller {
};
};
regards
Philipp
^ permalink raw reply
* [PATCH] mtd: nand: mxc: Fix mxc_v1 ooblayout
From: Boris Brezillon @ 2016-11-25 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58eed307-ee50-9727-7b64-891d1b969790@gmail.com>
On Fri, 25 Nov 2016 10:58:26 +0100
Marek Vasut <marek.vasut@gmail.com> wrote:
> 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 :)
Ideally, we should change ->eccbytes value in the
imx27_nand_devtype_data and imx21_nand_devtype_data definitions, but I
fear it could break other things.
I'll define a macro.
>
> > 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;
> >
>
>
^ permalink raw reply
* [RFC v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Philipp Zabel @ 2016-11-25 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8328a235-faeb-2218-4c49-a3f282599e95@linaro.org>
Am Donnerstag, den 24.11.2016, 18:20 +0800 schrieb zhangfei:
>
> On 2016?11?24? 17:50, Philipp Zabel wrote:
> > Am Donnerstag, den 24.11.2016, 17:40 +0800 schrieb zhangfei:
> >> On 2016?11?24? 17:26, Philipp Zabel wrote:
> >>> Am Mittwoch, den 23.11.2016, 16:07 +0800 schrieb Zhangfei Gao:
> >>>> Add DT bindings documentation for hi3660 SoC reset controller.
> >>>>
> >>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> >>>> ---
> >>>> .../bindings/reset/hisilicon,hi3660-reset.txt | 51 ++++++++++++++++++++++
> >>>> 1 file changed, 51 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >>>> new file mode 100644
> >>>> index 0000000..250daf2
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
> >>>> @@ -0,0 +1,51 @@
> >>>> +Hisilicon System Reset Controller
> >>>> +======================================
> >>>> +
> >>>> +Please also refer to reset.txt in this directory for common reset
> >>>> +controller binding usage.
> >>>> +
> >>>> +The reset controller registers are part of the system-ctl block on
> >>>> +hi3660 SoC.
> >>>> +
> >>>> +Required properties:
> >>>> +- compatible: should be
> >>>> + "hisilicon,hi3660-reset"
> >>>> +- #reset-cells: 1, see below
> >>>> +- hisi,rst-syscon: phandle of the reset's syscon.
> >>>> +- hisi,reset-bits: Contains the reset control register information
> >>>> + Should contain 2 cells for each reset exposed to
> >>>> + consumers, defined as:
> >>>> + Cell #1 : offset from the syscon register base
> >>>> + Cell #2 : bits position of the control register
> >>>> +
> >>>> +Example:
> >>>> + iomcu: iomcu at ffd7e000 {
> >>>> + compatible = "hisilicon,hi3660-iomcu", "syscon";
> >>>> + reg = <0x0 0xffd7e000 0x0 0x1000>;
> >>>> + };
> >>>> +
> >>>> + iomcu_rst: iomcu_rst_controller {
> >>> This should be
> >>> iomcu_rst: reset-controller {
> >>>
> >>>> + compatible = "hisilicon,hi3660-reset";
> >>>> + #reset-cells = <1>;
> >>>> + hisi,rst-syscon = <&iomcu>;
> >>>> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> >>>> + 0x20 0x10 /* 1: i2c1 */
> >>>> + 0x20 0x20 /* 2: i2c2 */
> >>>> + 0x20 0x8000000>; /* 3: i2c6 */
> >>>> + };
> >>> The reset lines are controlled through iomcu bits, is there a reason not
> >>> to put the iomcu_rst node inside the iomcu node? That way the
> >>> hisi,rst-syscon property could be removed and the syscon could be
> >>> retrieved via the reset-controller parent node.
> >> iomcu is common registers, controls clock and reset, etc.
> >> So we use syscon, without mapping the registers everywhere.
> >> It is common case in hisilicon, same in hi6220.
> >>
> >> Also the #clock-cells and #reset-cells can not be put in the same node,
> >> if they are both using probe, since reset_probe will not be called.
> >>
> >> So we use hisi,rst-syscon as a general solution.
> > What I meant is this:
> >
> > iomcu: iomcu at ffd7e000 {
> > compatible = "hisilicon,hi3660-iomcu", "syscon", "simple-mfd";
> > reg = <0x0 0xffd7e000 0x0 0x1000>;
> #clock-cells = <1>;
>
> In my test, if there add #clock-cells = <1>, reset_probe will not be
> called any more.
> Since clk_probe is called first.
> No matter iomcu_rst is child node or not.
I don't understand this, does the clock driver bind to the iomcu node
using CLK_OF_DECLARE_DRIVER(..., "hisilicon,hi3660-iomcu", ...)?
My comment was based only on this reset binding documentation and the
example DT snippet. Could you point me to the clock driver probe code
and show me a more complete part of the hi3660 device tree?
regards
Philipp
^ permalink raw reply
* [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes
From: Jean-Francois Moine @ 2016-11-25 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3188681480066911@web3h.yandex.ru>
On Fri, 25 Nov 2016 17:41:51 +0800
Icenowy Zheng <icenowy@aosc.xyz> wrote:
> After removing CLK_PLL_DE's assigned-clock, the kernel passes compilation.
The 'pll-de' and 'de' must have a fixed rate. Otherwise, if you do not
use the legacy u-boot, I don't know which can be the rate of the DE.
> 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
I put a 'pr_warn' message is case the EDID cannot be read.
Have you this message?
Anyway, there is a problem with the EDID:
- my Orange Pi 2 (H3) randomly fails to read it. But this succeeds after
rebooting once or twice.
- my Banana Pi M2+ (H3) reads it correctly each time.
- my Banana Pi M3 (A83T) can never read it.
BTW, on first tries, I was forcing a CEA mode thru the kernel command
line. This was working with the OPi2 and BPiM3, but there was no sound.
In the last version, I use a EDID in edid_firmware for having sound
with the BPiM3. This works fine.
But, forcing a CEA mode is no more possible, so, when the OPi2 cannot
read the EDID, the system switches to a VGA mode (default 1024x768)
which is not supported. It seems that this is your case.
So, in brief, if your board cannot read the EDID, put a EDID somewhere
and its path in /sys/module/drm_kms_helper/parameters/edid_firmware.
There will be no console, but X11 will work correctly.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 5/5] gpio: pl061: delete platform data handling
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>
Platform data is a remnant of board files and all boards using
the PL061 have been migrated to use device tree or ACPI instead.
The custom mechanism to set line by default as inputs/outputs has
been superceded by the GPIO-internal hogging mechanism.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-pl061.c | 41 +++--------------------------------------
1 file changed, 3 insertions(+), 38 deletions(-)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index cbcc631181e0..0a6bfd2b06e5 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -38,19 +38,6 @@
#define PL061_GPIO_NR 8
-struct pl061_platform_data {
- /* number of the first GPIO */
- unsigned gpio_base;
-
- /* number of the first IRQ.
- * If the IRQ functionality in not desired this must be set to 0.
- */
- unsigned irq_base;
-
- u8 directions; /* startup directions, 1: out, 0: in */
- u8 values; /* startup values */
-};
-
#ifdef CONFIG_PM
struct pl061_context_save_regs {
u8 gpio_data;
@@ -306,26 +293,13 @@ static struct irq_chip pl061_irqchip = {
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 *pl061;
- int ret, irq, i, irq_base;
+ int ret, irq;
pl061 = devm_kzalloc(dev, sizeof(*pl061), GFP_KERNEL);
if (pl061 == NULL)
return -ENOMEM;
- if (pdata) {
- pl061->gc.base = pdata->gpio_base;
- irq_base = pdata->irq_base;
- if (irq_base <= 0) {
- dev_err(&adev->dev, "invalid IRQ base in pdata\n");
- return -ENODEV;
- }
- } else {
- pl061->gc.base = -1;
- irq_base = 0;
- }
-
pl061->base = devm_ioremap_resource(dev, &adev->res);
if (IS_ERR(pl061->base))
return PTR_ERR(pl061->base);
@@ -336,6 +310,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
pl061->gc.free = gpiochip_generic_free;
}
+ pl061->gc.base = -1;
pl061->gc.get_direction = pl061_get_direction;
pl061->gc.direction_input = pl061_direction_input;
pl061->gc.direction_output = pl061_direction_output;
@@ -362,7 +337,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
pl061->parent_irq = irq;
ret = gpiochip_irqchip_add(&pl061->gc, &pl061_irqchip,
- irq_base, handle_bad_irq,
+ 0, handle_bad_irq,
IRQ_TYPE_NONE);
if (ret) {
dev_info(&adev->dev, "could not add irqchip\n");
@@ -371,16 +346,6 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
gpiochip_set_chained_irqchip(&pl061->gc, &pl061_irqchip,
irq, pl061_irq_handler);
- for (i = 0; i < PL061_GPIO_NR; i++) {
- if (pdata) {
- if (pdata->directions & (BIT(i)))
- pl061_direction_output(&pl061->gc, i,
- pdata->values & (BIT(i)));
- else
- pl061_direction_input(&pl061->gc, i);
- }
- }
-
amba_set_drvdata(adev, pl061);
dev_info(&adev->dev, "PL061 GPIO chip @%pa registered\n",
&adev->res.start);
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] gpio: pl061: move platform data into driver
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>
No boardfile defines any PL061 platform data anymore: the
Integrator IM/PD-1 includes the file but is not making use
of the struct. Let's delete the include and all references,
then move the platform data into the driver for later
consolidation into the driver state container.
The only resource defined by the IM/PD-1 is the IRQ which
is passed through the AMBA PrimeCell bus abstraction
struct amba_device.
Cc: arm at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks/Russell: I don't think this is any controversial
move, please ACK this if you're OK with it.
---
arch/arm/mach-integrator/impd1.c | 1 -
drivers/gpio/gpio-pl061.c | 14 +++++++++++++-
include/linux/amba/pl061.h | 16 ----------------
3 files changed, 13 insertions(+), 18 deletions(-)
delete mode 100644 include/linux/amba/pl061.h
diff --git a/arch/arm/mach-integrator/impd1.c b/arch/arm/mach-integrator/impd1.c
index ed9a01484030..a109f6482413 100644
--- a/arch/arm/mach-integrator/impd1.c
+++ b/arch/arm/mach-integrator/impd1.c
@@ -21,7 +21,6 @@
#include <linux/amba/bus.h>
#include <linux/amba/clcd.h>
#include <linux/amba/mmci.h>
-#include <linux/amba/pl061.h>
#include <linux/io.h>
#include <linux/platform_data/clk-integrator.h>
#include <linux/slab.h>
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 47f397236417..cbcc631181e0 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -23,7 +23,6 @@
#include <linux/gpio.h>
#include <linux/device.h>
#include <linux/amba/bus.h>
-#include <linux/amba/pl061.h>
#include <linux/slab.h>
#include <linux/pinctrl/consumer.h>
#include <linux/pm.h>
@@ -39,6 +38,19 @@
#define PL061_GPIO_NR 8
+struct pl061_platform_data {
+ /* number of the first GPIO */
+ unsigned gpio_base;
+
+ /* number of the first IRQ.
+ * If the IRQ functionality in not desired this must be set to 0.
+ */
+ unsigned irq_base;
+
+ u8 directions; /* startup directions, 1: out, 0: in */
+ u8 values; /* startup values */
+};
+
#ifdef CONFIG_PM
struct pl061_context_save_regs {
u8 gpio_data;
diff --git a/include/linux/amba/pl061.h b/include/linux/amba/pl061.h
deleted file mode 100644
index fb83c0453489..000000000000
--- a/include/linux/amba/pl061.h
+++ /dev/null
@@ -1,16 +0,0 @@
-#include <linux/types.h>
-
-/* platform data for the PL061 GPIO driver */
-
-struct pl061_platform_data {
- /* number of the first GPIO */
- unsigned gpio_base;
-
- /* number of the first IRQ.
- * If the IRQ functionality in not desired this must be set to 0.
- */
- unsigned irq_base;
-
- u8 directions; /* startup directions, 1: out, 0: in */
- u8 values; /* startup values */
-};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] gpio: pl061: rename variable from chip to pl061
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>
Rename the local variable "chip" referring to the struct pl061
state container to "pl061": we already have gpio_chip and irq_chip
in the driver, we are needlessly adding yet another "chip" to
the confusion.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-pl061.c | 186 +++++++++++++++++++++++-----------------------
1 file changed, 93 insertions(+), 93 deletions(-)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index b944aaefb59f..47f397236417 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -64,22 +64,22 @@ struct pl061 {
static int pl061_get_direction(struct gpio_chip *gc, unsigned offset)
{
- struct pl061 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
- return !(readb(chip->base + GPIODIR) & BIT(offset));
+ return !(readb(pl061->base + GPIODIR) & BIT(offset));
}
static int pl061_direction_input(struct gpio_chip *gc, unsigned offset)
{
- struct pl061 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
unsigned long flags;
unsigned char gpiodir;
- spin_lock_irqsave(&chip->lock, flags);
- gpiodir = readb(chip->base + GPIODIR);
+ spin_lock_irqsave(&pl061->lock, flags);
+ gpiodir = readb(pl061->base + GPIODIR);
gpiodir &= ~(BIT(offset));
- writeb(gpiodir, chip->base + GPIODIR);
- spin_unlock_irqrestore(&chip->lock, flags);
+ writeb(gpiodir, pl061->base + GPIODIR);
+ spin_unlock_irqrestore(&pl061->lock, flags);
return 0;
}
@@ -87,44 +87,44 @@ 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 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
unsigned long flags;
unsigned char gpiodir;
- spin_lock_irqsave(&chip->lock, flags);
- writeb(!!value << offset, chip->base + (BIT(offset + 2)));
- gpiodir = readb(chip->base + GPIODIR);
+ spin_lock_irqsave(&pl061->lock, flags);
+ writeb(!!value << offset, pl061->base + (BIT(offset + 2)));
+ gpiodir = readb(pl061->base + GPIODIR);
gpiodir |= BIT(offset);
- writeb(gpiodir, chip->base + GPIODIR);
+ writeb(gpiodir, pl061->base + GPIODIR);
/*
* gpio value is set again, because pl061 doesn't allow to set value of
* a gpio pin before configuring it in OUT mode.
*/
- writeb(!!value << offset, chip->base + (BIT(offset + 2)));
- spin_unlock_irqrestore(&chip->lock, flags);
+ writeb(!!value << offset, pl061->base + (BIT(offset + 2)));
+ spin_unlock_irqrestore(&pl061->lock, flags);
return 0;
}
static int pl061_get_value(struct gpio_chip *gc, unsigned offset)
{
- struct pl061 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
- return !!readb(chip->base + (BIT(offset + 2)));
+ return !!readb(pl061->base + (BIT(offset + 2)));
}
static void pl061_set_value(struct gpio_chip *gc, unsigned offset, int value)
{
- struct pl061 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
- writeb(!!value << offset, chip->base + (BIT(offset + 2)));
+ writeb(!!value << offset, pl061->base + (BIT(offset + 2)));
}
static int pl061_irq_type(struct irq_data *d, unsigned trigger)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct pl061 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
int offset = irqd_to_hwirq(d);
unsigned long flags;
u8 gpiois, gpioibe, gpioiev;
@@ -144,11 +144,11 @@ static int pl061_irq_type(struct irq_data *d, unsigned trigger)
}
- spin_lock_irqsave(&chip->lock, flags);
+ spin_lock_irqsave(&pl061->lock, flags);
- gpioiev = readb(chip->base + GPIOIEV);
- gpiois = readb(chip->base + GPIOIS);
- gpioibe = readb(chip->base + GPIOIBE);
+ gpioiev = readb(pl061->base + GPIOIEV);
+ gpiois = readb(pl061->base + GPIOIS);
+ gpioibe = readb(pl061->base + GPIOIBE);
if (trigger & (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW)) {
bool polarity = trigger & IRQ_TYPE_LEVEL_HIGH;
@@ -200,11 +200,11 @@ static int pl061_irq_type(struct irq_data *d, unsigned trigger)
offset);
}
- writeb(gpiois, chip->base + GPIOIS);
- writeb(gpioibe, chip->base + GPIOIBE);
- writeb(gpioiev, chip->base + GPIOIEV);
+ writeb(gpiois, pl061->base + GPIOIS);
+ writeb(gpioibe, pl061->base + GPIOIBE);
+ writeb(gpioiev, pl061->base + GPIOIEV);
- spin_unlock_irqrestore(&chip->lock, flags);
+ spin_unlock_irqrestore(&pl061->lock, flags);
return 0;
}
@@ -214,12 +214,12 @@ 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 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
struct irq_chip *irqchip = irq_desc_get_chip(desc);
chained_irq_enter(irqchip, desc);
- pending = readb(chip->base + GPIOMIS);
+ pending = readb(pl061->base + GPIOMIS);
if (pending) {
for_each_set_bit(offset, &pending, PL061_GPIO_NR)
generic_handle_irq(irq_find_mapping(gc->irqdomain,
@@ -232,27 +232,27 @@ 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 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
u8 gpioie;
- spin_lock(&chip->lock);
- gpioie = readb(chip->base + GPIOIE) & ~mask;
- writeb(gpioie, chip->base + GPIOIE);
- spin_unlock(&chip->lock);
+ spin_lock(&pl061->lock);
+ gpioie = readb(pl061->base + GPIOIE) & ~mask;
+ writeb(gpioie, pl061->base + GPIOIE);
+ spin_unlock(&pl061->lock);
}
static void pl061_irq_unmask(struct irq_data *d)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
- struct pl061 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
u8 gpioie;
- spin_lock(&chip->lock);
- gpioie = readb(chip->base + GPIOIE) | mask;
- writeb(gpioie, chip->base + GPIOIE);
- spin_unlock(&chip->lock);
+ spin_lock(&pl061->lock);
+ gpioie = readb(pl061->base + GPIOIE) | mask;
+ writeb(gpioie, pl061->base + GPIOIE);
+ spin_unlock(&pl061->lock);
}
/**
@@ -266,20 +266,20 @@ 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 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
- spin_lock(&chip->lock);
- writeb(mask, chip->base + GPIOIC);
- spin_unlock(&chip->lock);
+ spin_lock(&pl061->lock);
+ writeb(mask, pl061->base + GPIOIC);
+ spin_unlock(&pl061->lock);
}
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 *chip = gpiochip_get_data(gc);
+ struct pl061 *pl061 = gpiochip_get_data(gc);
- return irq_set_irq_wake(chip->parent_irq, state);
+ return irq_set_irq_wake(pl061->parent_irq, state);
}
static struct irq_chip pl061_irqchip = {
@@ -295,81 +295,81 @@ 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 *chip;
+ struct pl061 *pl061;
int ret, irq, i, irq_base;
- chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
- if (chip == NULL)
+ pl061 = devm_kzalloc(dev, sizeof(*pl061), GFP_KERNEL);
+ if (pl061 == NULL)
return -ENOMEM;
if (pdata) {
- chip->gc.base = pdata->gpio_base;
+ pl061->gc.base = pdata->gpio_base;
irq_base = pdata->irq_base;
if (irq_base <= 0) {
dev_err(&adev->dev, "invalid IRQ base in pdata\n");
return -ENODEV;
}
} else {
- chip->gc.base = -1;
+ pl061->gc.base = -1;
irq_base = 0;
}
- chip->base = devm_ioremap_resource(dev, &adev->res);
- if (IS_ERR(chip->base))
- return PTR_ERR(chip->base);
+ pl061->base = devm_ioremap_resource(dev, &adev->res);
+ if (IS_ERR(pl061->base))
+ return PTR_ERR(pl061->base);
- spin_lock_init(&chip->lock);
+ spin_lock_init(&pl061->lock);
if (of_property_read_bool(dev->of_node, "gpio-ranges")) {
- chip->gc.request = gpiochip_generic_request;
- chip->gc.free = gpiochip_generic_free;
+ pl061->gc.request = gpiochip_generic_request;
+ pl061->gc.free = gpiochip_generic_free;
}
- chip->gc.get_direction = pl061_get_direction;
- chip->gc.direction_input = pl061_direction_input;
- chip->gc.direction_output = pl061_direction_output;
- chip->gc.get = pl061_get_value;
- chip->gc.set = pl061_set_value;
- chip->gc.ngpio = PL061_GPIO_NR;
- chip->gc.label = dev_name(dev);
- chip->gc.parent = dev;
- chip->gc.owner = THIS_MODULE;
-
- ret = gpiochip_add_data(&chip->gc, chip);
+ pl061->gc.get_direction = pl061_get_direction;
+ pl061->gc.direction_input = pl061_direction_input;
+ pl061->gc.direction_output = pl061_direction_output;
+ pl061->gc.get = pl061_get_value;
+ pl061->gc.set = pl061_set_value;
+ pl061->gc.ngpio = PL061_GPIO_NR;
+ pl061->gc.label = dev_name(dev);
+ pl061->gc.parent = dev;
+ pl061->gc.owner = THIS_MODULE;
+
+ ret = gpiochip_add_data(&pl061->gc, pl061);
if (ret)
return ret;
/*
* irq_chip support
*/
- writeb(0, chip->base + GPIOIE); /* disable irqs */
+ writeb(0, pl061->base + GPIOIE); /* disable irqs */
irq = adev->irq[0];
if (irq < 0) {
dev_err(&adev->dev, "invalid IRQ\n");
return -ENODEV;
}
- chip->parent_irq = irq;
+ pl061->parent_irq = irq;
- ret = gpiochip_irqchip_add(&chip->gc, &pl061_irqchip,
+ ret = gpiochip_irqchip_add(&pl061->gc, &pl061_irqchip,
irq_base, handle_bad_irq,
IRQ_TYPE_NONE);
if (ret) {
dev_info(&adev->dev, "could not add irqchip\n");
return ret;
}
- gpiochip_set_chained_irqchip(&chip->gc, &pl061_irqchip,
+ gpiochip_set_chained_irqchip(&pl061->gc, &pl061_irqchip,
irq, pl061_irq_handler);
for (i = 0; i < PL061_GPIO_NR; i++) {
if (pdata) {
if (pdata->directions & (BIT(i)))
- pl061_direction_output(&chip->gc, i,
+ pl061_direction_output(&pl061->gc, i,
pdata->values & (BIT(i)));
else
- pl061_direction_input(&chip->gc, i);
+ pl061_direction_input(&pl061->gc, i);
}
}
- amba_set_drvdata(adev, chip);
+ amba_set_drvdata(adev, pl061);
dev_info(&adev->dev, "PL061 GPIO chip @%pa registered\n",
&adev->res.start);
@@ -379,20 +379,20 @@ 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 *chip = dev_get_drvdata(dev);
+ struct pl061 *pl061 = dev_get_drvdata(dev);
int offset;
- chip->csave_regs.gpio_data = 0;
- chip->csave_regs.gpio_dir = readb(chip->base + GPIODIR);
- chip->csave_regs.gpio_is = readb(chip->base + GPIOIS);
- chip->csave_regs.gpio_ibe = readb(chip->base + GPIOIBE);
- chip->csave_regs.gpio_iev = readb(chip->base + GPIOIEV);
- chip->csave_regs.gpio_ie = readb(chip->base + GPIOIE);
+ pl061->csave_regs.gpio_data = 0;
+ pl061->csave_regs.gpio_dir = readb(pl061->base + GPIODIR);
+ pl061->csave_regs.gpio_is = readb(pl061->base + GPIOIS);
+ pl061->csave_regs.gpio_ibe = readb(pl061->base + GPIOIBE);
+ pl061->csave_regs.gpio_iev = readb(pl061->base + GPIOIEV);
+ pl061->csave_regs.gpio_ie = readb(pl061->base + GPIOIE);
for (offset = 0; offset < PL061_GPIO_NR; offset++) {
- if (chip->csave_regs.gpio_dir & (BIT(offset)))
- chip->csave_regs.gpio_data |=
- pl061_get_value(&chip->gc, offset) << offset;
+ if (pl061->csave_regs.gpio_dir & (BIT(offset)))
+ pl061->csave_regs.gpio_data |=
+ pl061_get_value(&pl061->gc, offset) << offset;
}
return 0;
@@ -400,22 +400,22 @@ static int pl061_suspend(struct device *dev)
static int pl061_resume(struct device *dev)
{
- struct pl061 *chip = dev_get_drvdata(dev);
+ struct pl061 *pl061 = dev_get_drvdata(dev);
int offset;
for (offset = 0; offset < PL061_GPIO_NR; offset++) {
- if (chip->csave_regs.gpio_dir & (BIT(offset)))
- pl061_direction_output(&chip->gc, offset,
- chip->csave_regs.gpio_data &
+ if (pl061->csave_regs.gpio_dir & (BIT(offset)))
+ pl061_direction_output(&pl061->gc, offset,
+ pl061->csave_regs.gpio_data &
(BIT(offset)));
else
- pl061_direction_input(&chip->gc, offset);
+ pl061_direction_input(&pl061->gc, offset);
}
- writeb(chip->csave_regs.gpio_is, chip->base + GPIOIS);
- writeb(chip->csave_regs.gpio_ibe, chip->base + GPIOIBE);
- writeb(chip->csave_regs.gpio_iev, chip->base + GPIOIEV);
- writeb(chip->csave_regs.gpio_ie, chip->base + GPIOIE);
+ writeb(pl061->csave_regs.gpio_is, pl061->base + GPIOIS);
+ writeb(pl061->csave_regs.gpio_ibe, pl061->base + GPIOIBE);
+ writeb(pl061->csave_regs.gpio_iev, pl061->base + GPIOIEV);
+ writeb(pl061->csave_regs.gpio_ie, pl061->base + GPIOIE);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [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
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