* [GIT PULL] arm: mediatek: dts changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
although late, please pull the following changes.
Thanks,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-dts
for you to fetch changes up to 28d6e3647bd7c869bfc251f9a7e283d78cef5fc5:
arm: dts: mt2701: Use real clock for UARTs (2016-11-11 15:25:09 +0100)
----------------------------------------------------------------
- Add bindings for mtk-scpsys for mt2701
- Add clocks for auxadc on mt8173-evb
- Add nodes needed by clock controller for mt2701
- Use clocks from the clock controller for the uart of mt2701
----------------------------------------------------------------
Erin Lo (1):
arm: dts: mt2701: Use real clock for UARTs
James Liao (1):
arm: dts: mt2701: Add clock controller device nodes
Matthias Brugger (1):
arm64: dts: mt8173: Fix auxadc node
Shunli Wang (1):
soc: mediatek: Add MT2701 power dt-bindings
.../devicetree/bindings/soc/mediatek/scpsys.txt | 13 +++---
arch/arm/boot/dts/mt2701.dtsi | 50
+++++++++++++++++++---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 3 ++
include/dt-bindings/power/mt2701-power.h | 27 ++++++++++++
4 files changed, 83 insertions(+), 10 deletions(-)
create mode 100644 include/dt-bindings/power/mt2701-power.h
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Steven Rostedt @ 2016-11-14 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018200707.36e549ee@gandalf.local.home>
On Tue, 18 Oct 2016 20:07:07 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 18 Oct 2016 16:42:00 -0700
> Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> > In similar spirit to x86 and arm64 support, add a make_nop_arm()
> > to replace calls to mcount with a nop in sections that aren't
> > traced.
> >
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Acked-by: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>
> I can take this if I can get an ack from the ARM maintainers.
Any ARM maintainer want to ack this, or take it in their tree if they
haven't already?
-- Steve
^ permalink raw reply
* [GIT PULL] arm: mediatek: kconfig changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
although late, please pull the following changes.
Thanks,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-kconfig
for you to fetch changes up to 494975c9cc00f69bf71de0991dcebda9b2911aa0:
ARM: mediatek: clean up mach-mediatek/Makefile (2016-10-31 15:26:23
-0600)
----------------------------------------------------------------
- clean up mach-mediatek Makefile as kbuild only descends into the folder if
ARCH_MEDIATEK is enabled
----------------------------------------------------------------
Masahiro Yamada (1):
ARM: mediatek: clean up mach-mediatek/Makefile
arch/arm/mach-mediatek/Makefile | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
^ permalink raw reply
* [GIT PULL] arm: mediatek: soc changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
Although a bit late, please take the following changes into account.
Thanks a lot,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-soc
for you to fetch changes up to 112ef1882e12094c823937f9d72f2f598db02df7:
soc: mediatek: Add MT2701 scpsys driver (2016-10-31 00:58:58 +0100)
----------------------------------------------------------------
- prepare mtk-scpsys to for multi soc support
- add support for mt2701 to mtk-scpsys
----------------------------------------------------------------
James Liao (1):
soc: mediatek: Refine scpsys to support multiple platform
Shunli Wang (1):
soc: mediatek: Add MT2701 scpsys driver
drivers/soc/mediatek/Kconfig | 2 +-
drivers/soc/mediatek/mtk-scpsys.c | 465
++++++++++++++++++++++++++------------
2 files changed, 327 insertions(+), 140 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: at91: dt for 4.10
From: Alexandre Belloni @ 2016-11-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
at91 DT changes for 4.10, I don't expect much more this cycle.
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/abelloni/linux.git tags/at91-ab-4.10-dt1
for you to fetch changes up to b662a9dd8a1a03e6e2d61e74d3e7a08400edefb7:
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek (2016-11-14 17:04:24 +0100)
----------------------------------------------------------------
DT changes for 4.10:
- Many additions for sama5d2
- few non urgent fixes for sam9260ek, sama5d4 and sama5d2
----------------------------------------------------------------
Alexandre Belloni (4):
ARM: dts: at91: sama5d4: use proper sckc compatible
ARM: dts: at91: sama5d2: use correct sckc compatible
ARM: dts: at91: sama5d2: Add secumod node
ARM: dts: at91: sama5d2: Add securam node
Cyrille Pitchen (1):
ARM: dts: at91: sama5d2: enable FIFOs for high-speed i2c controllers
Marek Vasut (1):
ARM: dts: at91: sama5d4: Add new MA5D4EVK manufacturer compat
Peter Rosin (1):
dt-bindings: usb: atmel: fix a couple of copy-paste style typos
Sudeep Holla (1):
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
Sylvain Rochet (1):
ARM: dts: at91: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
.../devicetree/bindings/usb/atmel-usb.txt | 10 ++---
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 +-
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 +-
arch/arm/boot/dts/at91rm9200.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260ek.dts | 4 +-
arch/arm/boot/dts/at91sam9261.dtsi | 4 +-
arch/arm/boot/dts/at91sam9263.dtsi | 4 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 4 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 4 +-
arch/arm/boot/dts/at91sam9rl.dtsi | 4 +-
arch/arm/boot/dts/at91sam9x5.dtsi | 4 +-
arch/arm/boot/dts/sama5d2.dtsi | 47 ++++++++++++----------
arch/arm/boot/dts/sama5d3.dtsi | 4 +-
arch/arm/boot/dts/sama5d4.dtsi | 31 +++-----------
15 files changed, 60 insertions(+), 76 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/26c4f372/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Stephen Boyd @ 2016-11-14 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..dc347d3 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
Hm? vi?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Russell King - ARM Linux @ 2016-11-14 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114133641.09b1abfb@gandalf.local.home>
On Mon, Nov 14, 2016 at 01:36:41PM -0500, Steven Rostedt wrote:
> On Tue, 18 Oct 2016 20:07:07 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Tue, 18 Oct 2016 16:42:00 -0700
> > Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > > In similar spirit to x86 and arm64 support, add a make_nop_arm()
> > > to replace calls to mcount with a nop in sections that aren't
> > > traced.
> > >
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Acked-by: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > I can take this if I can get an ack from the ARM maintainers.
>
> Any ARM maintainer want to ack this, or take it in their tree if they
> haven't already?
Assuming it's been tested:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-14 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114181937.GG3096@e104818-lin.cambridge.arm.com>
On 11/14/2016 10:19 AM, Catalin Marinas wrote:
> On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
>> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
>>> On 11/02/2016 04:52 PM, Mark Rutland wrote:
>>>> On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
>>>>>
>>>>> __pa_symbol is technically the marco that should be used for kernel
>>>>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
>>>>
>>>> Nit: s/marco/macro/
>>>>
>>>> I see there are some other uses of __pa() that look like they could/should be
>>>> __pa_symbol(), e.g. in mark_rodata_ro().
>>>>
>>>> I guess strictly speaking those need to be updated to? Or is there a reason
>>>> that we should not?
>>>
>>> If the concept of __pa_symbol is okay then yes I think all uses of __pa
>>> should eventually be converted for consistency and debugging.
>>
>> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
>> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
>> for consistency with other architectures.
>
> At a quick grep, it seems to only be used by mips and x86 and a single
> place in mm/memblock.c.
>
> Since we haven't seen any issues on arm/arm64 without this macro, can we
> not just continue to use __pa()?
Technically yes but if it's introduced it may be confusing why it's being
used some places but not others. Maybe the bounds in the debug virtual check
should just be adjusted so we don't need __pa_symbol along with a nice fat
comment explaining why.
>
> Thanks.
>
Thanks,
Laura
^ permalink raw reply
* [GIT PULL] ARM: at91: drivers for 4.10
From: Alexandre Belloni @ 2016-11-14 18:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
A few fixes for the memory drivers and the support for the Secure SRAM
found on sama5d2.
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/abelloni/linux.git tags/at91-ab-4.10-drivers
for you to fetch changes up to 2ae2e28852f21ec9efc527c1f3ecc5f7c7e27e42:
misc: sram: add Atmel securam support (2016-11-07 23:43:28 +0100)
----------------------------------------------------------------
Drivers for 4.10:
- few fixes for the memory drivers
- minimal security module driver
- support for the Secure SRAM
----------------------------------------------------------------
Alexandre Belloni (4):
Documentation: dt: atmel-at91: Document secumod bindings
ARM: at91: add secumod register definitions
misc: sram: document new compatible
misc: sram: add Atmel securam support
Wei Yongjun (2):
memory: atmel-ebi: fix return value check in at91_ebi_dev_disable()
memory: atmel-sdramc: use builtin_platform_driver to simplify the code
.../devicetree/bindings/arm/atmel-at91.txt | 16 +++++++++
Documentation/devicetree/bindings/sram/sram.txt | 2 +-
drivers/memory/atmel-ebi.c | 2 +-
drivers/memory/atmel-sdramc.c | 6 +---
drivers/misc/sram.c | 42 ++++++++++++++++++----
include/soc/at91/atmel-secumod.h | 19 ++++++++++
6 files changed, 73 insertions(+), 14 deletions(-)
create mode 100644 include/soc/at91/atmel-secumod.h
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/287d05f1/attachment-0001.sig>
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Laura Abbott @ 2016-11-14 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112004449.30566-1-f.fainelli@gmail.com>
On 11/11/2016 04:44 PM, Florian Fainelli wrote:
> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
> debug_virt_to_phys() which helps catch vmalloc space addresses being
> passed. This is helpful in debugging bogus drivers that just assume
> linear mappings all over the place.
>
> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
> __virt_to_phys() as being the functional implementation of the address
> translation, so we special case the debug stub to call into
> __virt_to_phys directly.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/include/asm/memory.h | 4 ++++
> arch/arm64/include/asm/memory.h | 4 ++++
> include/asm-generic/memory_model.h | 4 ++++
> mm/debug.c | 15 +++++++++++++++
> 4 files changed, 27 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 76cbd9c674df..448dec9b8b00 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
> * translation for translating DMA addresses. Use the driver
> * DMA support - see dma-mapping.h.
> */
> +#ifndef CONFIG_DEBUG_VM
> #define virt_to_phys virt_to_phys
> static inline phys_addr_t virt_to_phys(const volatile void *x)
> {
> return __virt_to_phys((unsigned long)(x));
> }
> +#else
> +#define virt_to_phys debug_virt_to_phys
> +#endif
>
> #define phys_to_virt phys_to_virt
> static inline void *phys_to_virt(phys_addr_t x)
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b71086d25195..c9e436b28523 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
> * translation for translating DMA addresses. Use the driver
> * DMA support - see dma-mapping.h.
> */
> +#ifndef CONFIG_DEBUG_VM
> #define virt_to_phys virt_to_phys
> static inline phys_addr_t virt_to_phys(const volatile void *x)
> {
> return __virt_to_phys((unsigned long)(x));
> }
> +#else
> +#define virt_to_phys debug_virt_to_phys
> +#endif
>
> #define phys_to_virt phys_to_virt
> static inline void *phys_to_virt(phys_addr_t x)
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
> index 5148150cc80b..426085757258 100644
> --- a/include/asm-generic/memory_model.h
> +++ b/include/asm-generic/memory_model.h
> @@ -80,6 +80,10 @@
> #define page_to_pfn __page_to_pfn
> #define pfn_to_page __pfn_to_page
>
> +#ifdef CONFIG_DEBUG_VM
> +unsigned long debug_virt_to_phys(volatile void *address);
> +#endif /* CONFIG_DEBUG_VM */
> +
> #endif /* __ASSEMBLY__ */
>
> #endif
> diff --git a/mm/debug.c b/mm/debug.c
> index 9feb699c5d25..72b2ca9b11f4 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
> );
> }
>
> +#include <asm/memory.h>
> +#include <linux/mm.h>
> +
> +unsigned long debug_virt_to_phys(volatile void *address)
> +{
> + BUG_ON(is_vmalloc_addr((const void *)address));
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
> + defined(CONFIG_MICROBLAZE)
> + return __virt_to_phys(address);
> +#else
> + return virt_to_phys(address);
> +#endif
> +}
> +EXPORT_SYMBOL(debug_virt_to_phys);
> +
> #endif /* CONFIG_DEBUG_VM */
>
is_vmalloc_addr is necessary but not sufficient. This misses
cases like module addresses. The x86 version (CONFIG_DEBUG_VIRTUAL)
bounds checks against the known linear map to catch all cases.
I'm for a generic approach to this if it can catch all cases
that an architecture specific version would catch.
Thanks,
Laura
^ permalink raw reply
* [PATCH resend] input: touchscreen: silead: Add regulator support
From: Dmitry Torokhov @ 2016-11-14 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114144502.10595-2-hdegoede@redhat.com>
Hi Hans,
On Mon, Nov 14, 2016 at 03:45:02PM +0100, Hans de Goede wrote:
> On some tablets the touchscreen controller is powered by seperate
> regulators, add support for this.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/input/touchscreen/silead_gsl1680.txt | 2 +
> drivers/input/touchscreen/silead.c | 51 ++++++++++++++++++++--
> 2 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> index e844c3f..b726823 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> @@ -22,6 +22,8 @@ Optional properties:
> - touchscreen-inverted-y : See touchscreen.txt
> - touchscreen-swapped-x-y : See touchscreen.txt
> - silead,max-fingers : maximum number of fingers the touchscreen can detect
> +- vddio-supply : regulator phandle for controller VDDIO
> +- avdd-supply : regulator phandle for controller AVDD
>
> Example:
>
> diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> index f502c84..c6a1ae9 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -29,6 +29,7 @@
> #include <linux/input/touchscreen.h>
> #include <linux/pm.h>
> #include <linux/irq.h>
> +#include <linux/regulator/consumer.h>
>
> #include <asm/unaligned.h>
>
> @@ -72,6 +73,8 @@ enum silead_ts_power {
> struct silead_ts_data {
> struct i2c_client *client;
> struct gpio_desc *gpio_power;
> + struct regulator *vddio;
> + struct regulator *avdd;
> struct input_dev *input;
> char fw_name[64];
> struct touchscreen_properties prop;
> @@ -465,21 +468,52 @@ static int silead_ts_probe(struct i2c_client *client,
> if (client->irq <= 0)
> return -ENODEV;
>
> + data->vddio = devm_regulator_get_optional(dev, "vddio");
> + if (IS_ERR(data->vddio)) {
> + if (PTR_ERR(data->vddio) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + data->vddio = NULL;
Why do we ignore other errors? If there is an issue reported by
regulator framework we should net be ignoring it.
Unless regulator is truly optional (i.e. chip can work with some
functionality powered off) and not simply hidden (firmware takes care of
powering up system), we should not be using regulator_get_optional():
if regulator is absent from ACPI/DT/etc, regulator framework will supply
dummy regulator that you can enable/disable and not bothering checking
whether it is NULL or not.
Also, please consider using devm_regulator_bulk_get().
> + }
> +
> + data->avdd = devm_regulator_get_optional(dev, "avdd");
> + if (IS_ERR(data->avdd)) {
> + if (PTR_ERR(data->avdd) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + data->avdd = NULL;
> + }
> +
> + /*
> + * Enable regulators at probe and disable them at remove, we need
> + * to keep the chip powered otherwise it forgets its firmware.
> + */
> + if (data->vddio) {
> + error = regulator_enable(data->vddio);
> + if (error)
> + return error;
> + }
> +
> + if (data->avdd) {
> + error = regulator_enable(data->avdd);
> + if (error)
> + goto disable_vddio;
> + }
Use devm_add_action_or_reset() to work regulator_bulk_disable call into
devm stream. As it is you are leaving regulators on on unbind/remove.
> +
> /* Power GPIO pin */
> data->gpio_power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
> if (IS_ERR(data->gpio_power)) {
> if (PTR_ERR(data->gpio_power) != -EPROBE_DEFER)
> dev_err(dev, "Shutdown GPIO request failed\n");
> - return PTR_ERR(data->gpio_power);
> + error = PTR_ERR(data->gpio_power);
> + goto disable_avdd;
> }
>
> error = silead_ts_setup(client);
> if (error)
> - return error;
> + goto disable_avdd;
>
> error = silead_ts_request_input_dev(data);
> if (error)
> - return error;
> + goto disable_avdd;
>
> error = devm_request_threaded_irq(dev, client->irq,
> NULL, silead_ts_threaded_irq_handler,
> @@ -487,10 +521,19 @@ static int silead_ts_probe(struct i2c_client *client,
> if (error) {
> if (error != -EPROBE_DEFER)
> dev_err(dev, "IRQ request failed %d\n", error);
> - return error;
> + goto disable_avdd;
> }
>
> return 0;
> +
> +disable_avdd:
> + if (data->avdd)
> + regulator_disable(data->avdd);
> +disable_vddio:
> + if (data->vddio)
> + regulator_disable(data->vddio);
> +
> + return error;
> }
>
> static int __maybe_unused silead_ts_suspend(struct device *dev)
> --
> 2.9.3
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Dmitry Torokhov @ 2016-11-14 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114131114.6053-1-hdegoede@redhat.com>
On Mon, Nov 14, 2016 at 02:11:14PM +0100, Hans de Goede wrote:
> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
> adds bma180 chip-ids to the input bma150 driver, assuming that they are
> 100% compatible, but the bma180 is not compatible with the bma150 at all,
> it has 14 bits resolution instead of 10, and it has quite different
> control registers too.
>
> Treating the bma180 as a bma150 wrt its data registers will just result
> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
> registers are a different story. Things happen to just work but supporting
> that certainly does not make treating the bma180 the same as the bma150
> right.
>
> Since some setups depend on the evdev interface the bma150 driver offers
> on top of the bma180, we cannot simply remove the bma180 ids.
>
> So this commit only removes the bma180 id when the bma180 iio driver,
> which does treat the bma180 properly, is enabled.
>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thank you.
> ---
> Changes in v2:
> -Use IS_ENABLED(CONFIG_BMA180) instead of #ifdef CONFIG_BMA180
> ---
> drivers/input/misc/bma150.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
> index b0d4453..2124390 100644
> --- a/drivers/input/misc/bma150.c
> +++ b/drivers/input/misc/bma150.c
> @@ -538,8 +538,13 @@ static int bma150_probe(struct i2c_client *client,
> return -EIO;
> }
>
> + /*
> + * Note if the IIO CONFIG_BMA180 driver is enabled we want to fail
> + * the probe for the bma180 as the iio driver is preferred.
> + */
> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
> + if (chip_id != BMA150_CHIP_ID &&
> + (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
> return -EINVAL;
> }
> @@ -643,7 +648,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>
> static const struct i2c_device_id bma150_id[] = {
> { "bma150", 0 },
> +#if !IS_ENABLED(CONFIG_BMA180)
> { "bma180", 0 },
> +#endif
> { "smb380", 0 },
> { "bma023", 0 },
> { }
> --
> 2.9.3
>
--
Dmitry
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Bjorn Andersson @ 2016-11-14 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
> This patch adds support to PM8821 PMIC and interrupt support.
> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes from v1:
> - Removed unnessary locking spotted by Bjorn
> - updated register naming to reflect PM8821
> - lot of cleanups suggested by Bjorn
> - rebased on top of Linus Walleij's pm8xxx namespace
> cleanup patch.
Looks good, just some minor style nits below.
>
> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
> 2 files changed, 238 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index 37a088f..8f1b4ec 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
> Definition: must be one of:
> "qcom,pm8058"
> "qcom,pm8921"
> + "qcom,pm8821"
8 < 9, so move it one step up please.
>
> - #address-cells:
> Usage: required
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
[..]
> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
> +#define PM8821_SSBI_REG(m, b, offset) \
> + ((m == 0) ? \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
I like how this cleaned up the rest of the implementation.
[..]
> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
> + int master, int block)
> +{
> + int pmirq, irq, i, ret;
> + unsigned int bits;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
> + if (ret) {
> + pr_err("Failed reading %d block ret=%d", block, ret);
"Reading block %d failed ret=%d"
> + return;
> + }
> + if (!bits) {
> + pr_err("block bit set in master but no irqs: %d", block);
This seems more like a debug thing, either showing missbehaving hardware
or something odd in the driver. I think you should drop the print or
make it pr_debug().
> + return;
> + }
I would prefer that you just drop the entire if statement, it's just an
corner case optimization with a info print.
> +
> + /* Convert block offset to global block number */
> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
> +
> + /* Check IRQ bits */
> + for (i = 0; i < 8; i++) {
> + if (bits & BIT(i)) {
> + pmirq = block * 8 + i;
> + irq = irq_find_mapping(chip->irqdomain, pmirq);
> + generic_handle_irq(irq);
> + }
> + }
> +
Empty line
> +}
> +
> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
> + int master, u8 master_val)
> +{
> + int block;
> +
> + for (block = 1; block < 8; block++)
> + if (master_val & BIT(block))
> + pm8821_irq_block_handler(chip, master, block);
> +
Empty line
> +}
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
^
|
I see you're using vim :)
> + return;
> + }
> +
> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
Indentation
> + if (master & GENMASK(7, 1))
> + pm8821_irq_master_handler(chip, 0, master);
> +
> + /* bit 0 marks if master 1 contains any bits */
Dito
> + if (!(master & BIT(0)))
> + goto done;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
> + if (ret) {
> + pr_err("Failed to read master 1 ret=%d\n", ret);
> + return;
"goto done;" so that we pass chained_irq_exit()
> + }
> +
> + pm8821_irq_master_handler(chip, 1, master);
> +
> +done:
> + chained_irq_exit(irq_chip, desc);
> +}
> +
[..]
> +static void pm8821_irq_mask_ack(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + u8 block, master;
> + int irq_bit, rc;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> +
Empty line
> + if (rc) {
> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
"Failed to mask IRQ %d rc=%d\n"
> + return;
> + }
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> +
Empty line
> + if (rc) {
> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
> + pmirq, rc);
"Failed to clear IRQ %d rc=%d\n"
> + }
> +
Empty line
> +}
> +
> +static void pm8821_irq_unmask(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + int irq_bit, rc;
> + u8 block, master;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), ~BIT(irq_bit));
> +
Empty line
> + if (rc)
> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
"Failed to unmask IRQ %d rc=%d\n"
> +
Empty line
> +}
> +
> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
> + enum irqchip_irq_state which,
> + bool *state)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + int rc, pmirq = irqd_to_hwirq(d);
> + u8 block, irq_bit, master;
> + unsigned int bits;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
> + if (rc) {
> + pr_err("Failed Reading Status rc=%d\n", rc);
Odd capitalization, I suggest that you match it to the other functions
by:
"Reading status of IRQ %d failed rc=%d\n"
> + return rc;
> + }
> +
> + *state = !!(bits & BIT(irq_bit));
> +
> + return rc;
> +}
> +
[..]
>
> static int pm8xxx_probe(struct platform_device *pdev)
> {
> + const struct of_device_id *match;
> + const struct pm_irq_data *data;
> struct regmap *regmap;
> int irq, rc;
> unsigned int val;
> u32 rev;
> struct pm_irq_chip *chip;
> - unsigned int nirqs = PM8XXX_NR_IRQS;
> +
> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
> + if (!match) {
> + dev_err(&pdev->dev, "No matching driver data found\n");
> + return -EINVAL;
> + }
> +
> + data = match->data;
data = of_device_get_match_data(&pdev->dev); (from of_device.h)
Regards,
Bjorn
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: add missing options for systemd
From: Kevin Hilman @ 2016-11-14 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114160146.20679-1-nsekhar@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> Some kernel configuration options required for systemd
> support are missing in davinci_all_defconfig. Add them.
>
> This is based on recommendations in:
>
> http://cgit.freedesktop.org/systemd/systemd/tree/README
>
> Options which kernel enables by default (and will thus be removed
> upon next savedefconfig update) are not included.
>
> Tested on OMAP-L138 LCDK board with fully up to date armv5
> archlinux filesystem.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-14 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU26tx-1bLKNpzYJ0UCeFJ-SczZOca1dYdt5mCGDxAuKTQ@mail.gmail.com>
So, someone merged a patch which makes mmcblk devices follow the
host controller numbering.
Now my cubox-i fails to boot correctly because the SD card in the
_only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
USDHC1 is wired to the on-microsom WiFi, and never has anything
remotely near a SD card or eMMC present. So, this change is
confusing on these platforms.
Moreover, this is _going_ to break SolidRun distros if people upgrade
their kernels.
It may be appropriate for eMMC, but it's not appropriate everywhere.
This is a user visible _regression_ in 4.9-rc. Whoever did this,
please revert whatever change caused this, and next time limit it
to only eMMC.
Thanks.
On Fri, Oct 28, 2016 at 09:45:00AM -0700, Tim Harvey wrote:
> On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I have an IMX6 board that has the following:
> >> sdhc1: mmc0: sdio radio
> >> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
> >>
> >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> >> registered as /dev/mmcblk1 so that permanent storage is the first
> >> mmcblk device as I think this is more intuitive however currently
> >> these get instanced in the order they appear in the imx6qdl.dtsi
> >> device-tree configuration and are not able to be mapped the way I want
> >> them in my dts file.
> >>
> >> Is there a way, or if not is there a desire for a way, to specify the
> >> order of /dev/mmcblk devices via device-tree?
> >
> > As with many other devices, there is no standard way of controlling the
> > Linux enumeration (and given the ID space is shared with other dynamic
> > devices it's not something that could generally work).
> >
> > These should be refererd to by UUID if possible.
> >
> > If not, we could cosider adding a by-dt-path or something like that.
> >
> > Thanks,
> > Mark.
>
> Mark / Javier/ Fabio,
>
> Thanks - this is very useful.
>
> Yes, I agree that using UUID's is the way to go and now I see how that
> can be easily accessed via uboot 'part' command.
>
> Regards,
>
> Tim
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-11-14 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFofZdFfGA8gbS9FJxAX5Ub-s8yZWDcNVOgwiEBpho4oyw@mail.gmail.com>
Hi,
On 11/11/2016 06:34 AM, Ulf Hansson wrote:
> On 10 November 2016 at 20:56, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Rob, Ulf, Jon,
>>
>> On 10/27/2016 08:15 AM, Dave Gerlach wrote:
>>>
>>> +Jon
>>> On 10/26/2016 04:59 PM, Rob Herring wrote:
>>>>
>>>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com>
>>>> wrote:
>>>>>
>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>
>>>>>> Hi,
>>>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>>>>>
>>>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>>>
>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>>>> control device power states.
>>>>>>>>
>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>
>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>> ---
>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54
>>>>>>>> +++++++++++++
>>>>>>>> MAINTAINERS | 2 +
>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>> ++++++++++++++++++++++
>>>>>>>> 3 files changed, 146 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..32f38a349656
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> @@ -0,0 +1,54 @@
>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>> +---------------------------------------------
>>>>>>>> +
>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>> that is
>>>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>> system
>>>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>>>> domain
>>>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>>>> use of
>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>> +
>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>> +
>>>>>>>> +PM Domain Node
>>>>>>>> +==============
>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>> PMMC,
>>>>>>>> +which in this case is the single implementation as documented by the
>>>>>>>> generic
>>>>>>>> +PM domain bindings in
>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the
>>>>>>>> devices.
>>>>>>>>
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +k2g_pds: k2g_pds {
>>>>>>>
>>>>>>>
>>>>>>> should use generic name like "power-contoller", e.g. k2g_pds:
>>>>>>> power-controller
>>>>>>
>>>>>>
>>>>>> Ok, that makes more sense.
>>>>>>
>>>>>>>
>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>> + ti,sci = <&pmmc>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +PM Domain Consumers
>>>>>>>> +===================
>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>> provide
>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>> device
>>>>>>>> +specific ID that identifies the device.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>> node.
>>>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI
>>>>>>>> to
>>>>>>>> + be used for device control.
>>>>>>>
>>>>>>>
>>>>>>> This ID doesn't look right.
>>>>>>>
>>>>>>> Why not use #power-domain-cells = <1> and pass the index in the DT?
>>>>>>> ...
>>>>
>>>>
>>>> Exactly. ti,sci-id is a NAK for me.
>>>
>>>
>>> I was told not to use the onecell during v1 discussion. I agree this would
>>> be
>>> ideal but I cannot due to what the bindings represent, the phandle
>>> parameter is
>>> an index into a list of genpds, whereas we need an actual ID number we can
>>> use
>>> and I do not have the ability to get that from the phandle.
>>>
>>> @Ulf/Jon, is there any hope of bringing back custom xlate functions for
>>> genpd
>>> providers? I don't have a good background on why it was even removed. I
>>> can
>>> maintain a single genpd for all devices but I need a way to parse this ID,
>>> whether it's from a separate property or a phandle. It is locked now to
>>> indexing
>>> into a list of genpds but I need additional per device information for
>>> devices
>>> bound to a genpd and I need either a custom parameter or the ability to
>>> parse
>>> the phandle myself.
>>>
>>
>> Any comments here? The meaning of the phandle onecell is fixed in the genpd
>> framework so I'm not sure how we want to move forward with this, I need to
>> pass a power domain ID to the genpd driver, and if this shouldn't be a new
>> property I'm not sure what direction we should take.
>>
>> Regards,
>> Dave
>>
>>
>>>>
>>>>>>>
>>>>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for
>>>>>>>> k2g.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +uart0: serial at 02530c00 {
>>>>>>>> + compatible = "ns16550a";
>>>>>>>> + ...
>>>>>>>> + power-domains = <&k2g_pds>;
>>>>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>>>>
>>>>>>>
>>>>>>> ... like this:
>>>>>>>
>>>>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>>>>
>>>>>>
>>>>>> That's how I did it in version one actually. I was able to define my
>>>>>> own xlate function to parse the phandle and get that index, but Ulf
>>>>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>>>>> providers and dropped the concept of adding your own xlate. This locks
>>>>>> the onecell approach to using a fixed static array of genpds that get
>>>>>> indexed into (without passing the index to the provider, just the
>>>>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>>>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>>>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>>>>> the sci-id and then use it in the genpd device start/stop hooks.
>>>>
>>>>
>>>> I have no idea what any of this means. All sounds like driver
>>>> architecture, not anything to do with bindings.
>>>
>>>
>>> This was a response to Kevin, not part of binding description.
>>>
>>>>
>>>>>
>>>>> Ah, right. I remember now. This approach allows you to use a single
>>>>> genpd as discussed earlier.
>>>>>
>>>>> Makes sense now, suggestion retracted.
>>>>
>>>>
>>>> IIRC, the bindings in Jon's case had a node for each domain and didn't
>>>> need any additional property.
>>>
>>>
>>> Yes but we only have one domain and index into it, not into a list of
>>> domains,
>
> Exactly. And this my main point as well. We are not talking about a
> domain property but a device property.
>
>>> so the additional property is solving a different problem.
>
> Yes.
>
> Perhaps you could try to elaborate about what the TI SCI ID really
> represents for the device, as to help Rob understand the bigger
> picture?
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Thanks for the response. Yes, you've pretty much hit it on the head. It
is not an index into a list of genpds but rather identifies the device
*within* a single genpd. It is a property specific to each device that
resides in a ti-sci-genpd, not a mapping describing which genpd the
device belongs to. The generic power domain binding is concerned with
mapping the device to a specific genpd, which is does fine for us, but
we have a sub mapping for devices that exist inside a genpd which, we
must describe as well, hence the ti,sci-id.
Regards,
Dave
>
> Hope that helps.
>
> Kind regards
> Uffe
>
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aee5072c-4e09-547e-2f58-7b2106bced3c@redhat.com>
On 11/14/2016 10:45 AM, Laura Abbott wrote:
> On 11/11/2016 04:44 PM, Florian Fainelli wrote:
>> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
>> debug_virt_to_phys() which helps catch vmalloc space addresses being
>> passed. This is helpful in debugging bogus drivers that just assume
>> linear mappings all over the place.
>>
>> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
>> __virt_to_phys() as being the functional implementation of the address
>> translation, so we special case the debug stub to call into
>> __virt_to_phys directly.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/include/asm/memory.h | 4 ++++
>> arch/arm64/include/asm/memory.h | 4 ++++
>> include/asm-generic/memory_model.h | 4 ++++
>> mm/debug.c | 15 +++++++++++++++
>> 4 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index 76cbd9c674df..448dec9b8b00 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index b71086d25195..c9e436b28523 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
>> index 5148150cc80b..426085757258 100644
>> --- a/include/asm-generic/memory_model.h
>> +++ b/include/asm-generic/memory_model.h
>> @@ -80,6 +80,10 @@
>> #define page_to_pfn __page_to_pfn
>> #define pfn_to_page __pfn_to_page
>>
>> +#ifdef CONFIG_DEBUG_VM
>> +unsigned long debug_virt_to_phys(volatile void *address);
>> +#endif /* CONFIG_DEBUG_VM */
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/mm/debug.c b/mm/debug.c
>> index 9feb699c5d25..72b2ca9b11f4 100644
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
>> );
>> }
>>
>> +#include <asm/memory.h>
>> +#include <linux/mm.h>
>> +
>> +unsigned long debug_virt_to_phys(volatile void *address)
>> +{
>> + BUG_ON(is_vmalloc_addr((const void *)address));
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
>> + defined(CONFIG_MICROBLAZE)
>> + return __virt_to_phys(address);
>> +#else
>> + return virt_to_phys(address);
>> +#endif
>> +}
>> +EXPORT_SYMBOL(debug_virt_to_phys);
>> +
>> #endif /* CONFIG_DEBUG_VM */
>>
>
> is_vmalloc_addr is necessary but not sufficient. This misses
> cases like module addresses.
Indeed, thanks.
> The x86 version (CONFIG_DEBUG_VIRTUAL)
> bounds checks against the known linear map to catch all cases.
> I'm for a generic approach to this if it can catch all cases
> that an architecture specific version would catch.
For one, my patch causes an early BUG to occur on ARM64 during
arch/arm64/kernel/setup.c::setup_arch when we call
cpu_uninstall_idmap(). I suspect there could be a bunch of little checks
like these where we'd have to have an architecture specific "is this
physical/virtual address valid" that may make a generic implementation
hard to come up with.
--
Florian
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a1116e3f-32d2-aa2d-9404-1d8147bd8500@codeaurora.org>
On 14/11/16 18:40, Stephen Boyd wrote:
> On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
>> index 7f9620e..dc347d3 100644
>> --- a/drivers/mfd/qcom-pm8xxx.c
>> +++ b/drivers/mfd/qcom-pm8xxx.c
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
>
> Hm? vi?
yes.. That was good catch!! will fix it in next version...
>
^ permalink raw reply
* [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support
From: Stephen Boyd @ 2016-11-14 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111074017.GA21045@b29397-desktop>
Quoting Peter Chen (2016-11-10 23:40:17)
> On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-10-18 02:31:40)
> > > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> > > > I've also sent separate patches for other minor pieces to make this
> > > > all work. The full tree can be found here[2], hacks and all to get
> > > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > > and ifc6410 with configfs gadgets and otg cables.
> > > >
> > > > Patches based on v4.8-rc1
> >
> > Oops should be v4.9-rc1 here.
> >
> > > >
> > > > Changes from v4:
> > > > * Picked up Acks from Rob
> > > > * Updated HS phy init sequence DT property to restrict it to offsets
> > >
> > > I remembered that you got all my acks for chipidea patches, right? I did
> > > not check for this series.
> >
> > Sorry I've added in one more patch
> >
> > usb: chipidea: Emulate OTGSC interrupt enable path
> >
> > to fix extcon interrupt emulation even further.
> >
> > >
> > > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a
> > > provider" [1] still not be accepted, I need this patch to be merged
> > > first, then apply your chipidea part, otherwise, there is a building
> > > warning.
> > >
> > > [1] https://patchwork.kernel.org/patch/9322583/
> >
> > Yes, I'm going to resend that patch now. I hope that David will apply it
> > for -rc2.
>
> Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on
> it), your GPU fix is still not there.
>
It looks like the patch is in drm-misc. I think they're going to hold
off on merging it until the next merge window though. fb80016af071 is
the commit in drm-misc tree and in linux-next. I'm not sure anything can
be done here besides a cross tree merge or ignore the warning?
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114185621.GC27931@tuxbot>
On 14/11/16 18:56, Bjorn Andersson wrote:
> On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
>
>> This patch adds support to PM8821 PMIC and interrupt support.
>> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Changes from v1:
>> - Removed unnessary locking spotted by Bjorn
>> - updated register naming to reflect PM8821
>> - lot of cleanups suggested by Bjorn
>> - rebased on top of Linus Walleij's pm8xxx namespace
>> cleanup patch.
>
> Looks good, just some minor style nits below.
Thanks, I will address all the comments in next version.
>
>>
>> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
>> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
>> 2 files changed, 238 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> index 37a088f..8f1b4ec 100644
>> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
>> Definition: must be one of:
>> "qcom,pm8058"
>> "qcom,pm8921"
>> + "qcom,pm8821"
>
> 8 < 9, so move it one step up please.
sure.. makes sense.
>
>>
>> - #address-cells:
>> Usage: required
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> [..]
>> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
>> +#define PM8821_SSBI_REG(m, b, offset) \
>> + ((m == 0) ? \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
>> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
>> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
>> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
>> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
>
> I like how this cleaned up the rest of the implementation.
>
> [..]
>
>> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
>> + int master, int block)
>> +{
>> + int pmirq, irq, i, ret;
>> + unsigned int bits;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
>> + if (ret) {
>> + pr_err("Failed reading %d block ret=%d", block, ret);
>
> "Reading block %d failed ret=%d"
yep.
>
>> + return;
>> + }
>> + if (!bits) {
>> + pr_err("block bit set in master but no irqs: %d", block);
>
> This seems more like a debug thing, either showing missbehaving hardware
> or something odd in the driver. I think you should drop the print or
> make it pr_debug().
okay.
>
>> + return;
>> + }
>
> I would prefer that you just drop the entire if statement, it's just an
> corner case optimization with a info print.
>
i will have a closer look at this part once again.
>> +
>> + /* Convert block offset to global block number */
>> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
>> +
>> + /* Check IRQ bits */
>> + for (i = 0; i < 8; i++) {
>> + if (bits & BIT(i)) {
>> + pmirq = block * 8 + i;
>> + irq = irq_find_mapping(chip->irqdomain, pmirq);
>> + generic_handle_irq(irq);
>> + }
>> + }
>> +
>
> Empty line
will fix all the empty lines in next version.
>
>> +}
>> +
>> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
>> + int master, u8 master_val)
>> +{
>> + int block;
>> +
>> + for (block = 1; block < 8; block++)
>> + if (master_val & BIT(block))
>> + pm8821_irq_block_handler(chip, master, block);
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
> ^
> |
> I see you're using vim :)
>
>> + return;
>> + }
>> +
>> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
>
> Indentation
>
>> + if (master & GENMASK(7, 1))
>> + pm8821_irq_master_handler(chip, 0, master);
>> +
>> + /* bit 0 marks if master 1 contains any bits */
>
> Dito
yep.
>
>> + if (!(master & BIT(0)))
>> + goto done;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
>> + if (ret) {
>> + pr_err("Failed to read master 1 ret=%d\n", ret);
>> + return;
>
> "goto done;" so that we pass chained_irq_exit()
yes,
>
>> + }
>> +
>> + pm8821_irq_master_handler(chip, 1, master);
>> +
>> +done:
>> + chained_irq_exit(irq_chip, desc);
>> +}
>> +
>
> [..]
>
>> +static void pm8821_irq_mask_ack(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + u8 block, master;
>> + int irq_bit, rc;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to mask IRQ %d rc=%d\n"
>
>> + return;
>> + }
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
>> + pmirq, rc);
>
> "Failed to clear IRQ %d rc=%d\n"
>
>> + }
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_unmask(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + int irq_bit, rc;
>> + u8 block, master;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), ~BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc)
>> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to unmask IRQ %d rc=%d\n"
will update it in next version.
>
>> +
>
> Empty line
>
>> +}
>> +
>> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which,
>> + bool *state)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + int rc, pmirq = irqd_to_hwirq(d);
>> + u8 block, irq_bit, master;
>> + unsigned int bits;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
>> + if (rc) {
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>
> Odd capitalization, I suggest that you match it to the other functions
> by:
>
> "Reading status of IRQ %d failed rc=%d\n"
>
Okay
>> + return rc;
>> + }
>> +
>> + *state = !!(bits & BIT(irq_bit));
>> +
>> + return rc;
>> +}
>> +
>
> [..]
>
>>
>> static int pm8xxx_probe(struct platform_device *pdev)
>> {
>> + const struct of_device_id *match;
>> + const struct pm_irq_data *data;
>> struct regmap *regmap;
>> int irq, rc;
>> unsigned int val;
>> u32 rev;
>> struct pm_irq_chip *chip;
>> - unsigned int nirqs = PM8XXX_NR_IRQS;
>> +
>> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
>> + if (!match) {
>> + dev_err(&pdev->dev, "No matching driver data found\n");
>> + return -EINVAL;
>> + }
>> +
>> + data = match->data;
>
> data = of_device_get_match_data(&pdev->dev); (from of_device.h)
This is good one.. I will use it in next version.
> Regards,
> Bjorn
>
^ permalink raw reply
* [PATCH V2] dmaengine: qcom_hidma: cleanup sysfs entries during remove
From: Sinan Kaya @ 2016-11-14 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <457a0a58-fcb5-26d6-99e6-7192dd071e1c@codeaurora.org>
Hi Vinod,
On 11/13/2016 10:10 PM, Sinan Kaya wrote:
> On 11/13/2016 10:04 PM, Vinod Koul wrote:
>> On Wed, Oct 19, 2016 at 02:42:46PM -0400, Sinan Kaya wrote:
>>> The 4.8-rc8 kernel is printing duplicate file entry warnings while removing
>>> the HIDMA object. This is caused by stale sysfs entries remaining from the
>>> previous execution.
>>>
>>> _sysfs_warn_dup+0x5c/0x78
>>> sysfs_add_file_mode_ns+0x13c/0x1c0
>>> sysfs_create_file_ns+0x2c/0x40
>>> device_create_file+0x54/0xa0
>>> hidma_probe+0x7c8/0x808
>>>
>>> Create hidma_sysfs_init and hidma_sysfs_uninit functions and call them from
>>> the probe and remove path. To do proper clean up, adding the attrs object
>>> to the device data structure to keep it around until remove call is made.
>>
>> This doesnt apply for me, I think due to other patches applied..
>>
>
> OK. Let me rebase.
>
I fetched your topic/qcom branch and applied this patch on top.
This is what I see at this moment.
22f20f5 dmaengine: qcom_hidma: cleanup sysfs entries during remove
8cc12b2 dmaengine: qcom_hidma: hide MSI handler when unused
87ffcea dmaengine: qcom_hidma: remove unneeded of_node_put()
1c0e3e8 dmaengine: qcom_hidma: add MSI support for interrupts
I posted V3 a minute ago with the contents of 22f20f5.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Maxime Ripard @ 2016-11-14 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-4-git-send-email-sudeep.holla@arm.com>
On Mon, Nov 14, 2016 at 03:44:10PM +0000, Sudeep Holla wrote:
> Though the mmc core driver will continue to support the legacy
> "enable-sdio-wakeup" property to enable SDIO as the wakeup source,
> "wakeup-source" is the new standard binding.
>
> This patch replaces the legacy "enable-sdio-wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/a2450401/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-1-hdegoede@redhat.com>
Hi,
On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> 2 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
> allwinner,pins = "PG3";
> };
>
> -&i2c1 {
> - icn8318: touchscreen at 40 {
> - compatible = "chipone,icn8318";
> - reg = <0x40>;
> - interrupt-parent = <&pio>;
> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> - pinctrl-names = "default";
> - pinctrl-0 = <&ts_wake_pin_p66>;
> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> - touchscreen-size-x = <800>;
> - touchscreen-size-y = <480>;
> - touchscreen-inverted-x;
> - touchscreen-swapped-x-y;
> - };
> -};
> -
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
> -
> - ts_wake_pin_p66: ts_wake_pin at 0 {
> - allwinner,pins = "PB3";
> - allwinner,function = "gpio_out";
> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> - };
> -
> };
>
> ®_usb0_vbus {
> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> };
>
> +&touchscreen {
> + compatible = "chipone,icn8318";
> + reg = <0x40>;
> + /* The P66 uses a different EINT then the reference design */
> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-swapped-x-y;
> + status = "okay";
> +};
> +
> &uart1 {
> /* The P66 uses the uart pins as gpios */
> status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
> */
> #include "sunxi-reference-design-tablet.dtsi"
>
> +#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pwm/pwm.h>
>
> / {
> @@ -84,6 +85,23 @@
> };
>
> &i2c1 {
> + /*
> + * The gsl1680 is rated at 400KHz and it will not work reliable at
> + * 100KHz, this has been confirmed on multiple different q8 tablets.
> + * All other devices on this bus are also rated for 400KHz.
> + */
> + clock-frequency = <400000>;
> +
> + touchscreen: touchscreen {
> + interrupt-parent = <&pio>;
> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_power_pin>;
> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + /* Tablet dts must provide reg and compatible */
> + status = "disabled";
> + };
> +
> pcf8563: rtc at 51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> @@ -125,6 +143,13 @@
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
>
> + ts_power_pin: ts_power_pin {
> + allwinner,pins = "PB3";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.
You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/7e78a172/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-2-hdegoede@redhat.com>
On Sun, Nov 13, 2016 at 08:22:03PM +0100, Hans de Goede wrote:
> On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
> config at as such in sun8i-reference-design-tablet.dtsi.
>
> Note that it will only be enabled when it us actually referenced by
> a foo-supply property in the touchscreen node, so for tablets which
> do not use ldo_io1 as vcc-touchscreen, it will be disabled.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4197396f/attachment.sig>
^ 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