* Disabling an interrupt in the handler locks the system up
From: Thomas Gleixner @ 2016-10-21 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580A70B9.8060507@free.fr>
On Fri, 21 Oct 2016, Mason wrote:
> On 21/10/2016 21:14, Marc Zyngier wrote:
> > If connecting a device that signals its interrupt as level low to an
> > input line configured as level high doesn't strike you as a major
> > issue, nothing will. At that point, you can put anything you want in
> > your DT.
>
> If I understand correctly, you are saying that I should have
> specified IRQ_TYPE_LEVEL_LOW, instead of IRQ_TYPE_LEVEL_HIGH?
>
> If the HW outputs 1 when idle, and 0 when busy, that
> is level low? (Sorry if this is obvious, I'm absolutely
> clueless in this subject matter.)
We describe the level which is raising the interrupt. So in your case the
line goes to 0 when the interrupt is active, so the level is LOW.
Thanks,
tglx
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Mason @ 2016-10-21 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021201448.3f4a0a7a@arm.com>
On 21/10/2016 21:14, Marc Zyngier wrote:
> Mason wrote:
>
>> On 21/10/2016 19:46, Marc Zyngier wrote:
>>
>>> On 21/10/16 17:37, Mason wrote:
>>>
>>>> On my platform, one HW block pulls the interrupt line high
>>>> as long as it remains idle, and low when it is busy.
>>>>
>>>> The device tree node is:
>>>>
>>>> test at 22222 {
>>>> compatible = "vendor,testme";
>>>> interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
>>>> };
>>>
>>> I assume that this is for the sake of the discussion, and that you do
>>> not actually intend to put together such a monstrosity.
>>
>> It's just missing a reg properties to be a valid node, right?
>
> If connecting a device that signals its interrupt as level low to an
> input line configured as level high doesn't strike you as a major
> issue, nothing will. At that point, you can put anything you want in
> your DT.
If I understand correctly, you are saying that I should have
specified IRQ_TYPE_LEVEL_LOW, instead of IRQ_TYPE_LEVEL_HIGH?
If the HW outputs 1 when idle, and 0 when busy, that
is level low? (Sorry if this is obvious, I'm absolutely
clueless in this subject matter.)
>>>> I wrote a minimal driver which registers the irq.
>>>> And in the interrupt handler, I disable said irq.
>>>>
>>>> Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as
>>>> it is registered (because the block is idle).
>>>>
>>>> Here is the code I've been running, request_irq doesn't return.
>>>
>>> [...]
>>>
>>>> And here's what I get when I try to load the module:
>>>> (I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21)
>>>
>>> [...]
>>>
>>>> Are we not supposed to disable the irq in the handler?
>>>
>>> You can. It then depends on what your interrupt controller does to
>>> actually ensure that the interrupt is disabled. Only you can trace it on
>>> your HW to find out.
>>
>> I'm using an upstream driver on v4.9-rc1
>>
>> http://lxr.free-electrons.com/source/drivers/irqchip/irq-tango.c
>>
>> Given that the system locks up, is it possible there is a bug
>> in the driver?
>
> That's possible.
>
>> Which call-back handles enabling/disabling interrupts?
>
> How about irq_unmask/irq_mask?
I tried following the source from disable_irq_nosync()
as far down as I could.
disable_irq_nosync ->
__disable_irq_nosync ->
__disable_irq ->
irq_disable -> ??
http://lxr.free-electrons.com/source/kernel/irq/chip.c#L232
I don't know if desc->irq_data.chip->irq_disable is defined
by the driver I'm using?
I don't know how the trail goes to irq_mask?
Regards.
^ permalink raw reply
* [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy
From: Stephen Boyd @ 2016-10-21 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021022030.GB16461@b29397-desktop>
Quoting Peter Chen (2016-10-20 19:20:30)
> On Thu, Oct 20, 2016 at 04:20:38PM -0700, Stephen Boyd wrote:
> > Quoting Stephen Boyd (2016-10-17 18:56:36)
> > > +
> > > +static int
> > > +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> > > + void *ptr)
> > > +{
> > > + struct qcom_usb_hs_phy *uphy;
> > > + int is_host;
> > > + u8 addr;
> > > +
> > > + uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> > > + is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
> >
> > Please don't apply this patch. This call now deadlocks on v4.9-rc1
> > because of how extcon_get_cable_state_() now grabs a lock that is
> > already held here when we're inside the notifier. It's not really
> > required that we grab the lock in extcon there, but this has exposed a
> > flaw in the logic anyway. We don't know if the id pin is going to toggle
> > before or after this function is called, so we should really keep track
> > of both vbus and id state in this driver and then do the same ulpi
> > writes from two different notifiers for both vbus and id pin. We would
> > be duplicating work sometimes, but that's pretty much the best solution
> > I can come up with. Otherwise it's racy.
> >
>
> Why you need to care id status? If EXTCON_USB event has happened, and
> event is true, you can set, otherwise, it is clear operation, that's
> to say you may not need have id extcon phandle, do you think so?
>
I need to add a comment to the code here because I forgot what was going
on.
Either way, this code is pulling D+ up when we're in device mode. We
don't want to do the pullup if we're a host, and vbus extcon only tells
us if the cable is attached so we can't just rely on that one bit of
information.
I suppose that's not really appropriate to do via extcon though in the
phy driver though, so I'm thinking that it should be rewritten to use
the phy_set_mode() feature of the phy framework. Basically,
ci_udc_pullup() will call phy_set_mode() with PHY_MODE_USB_DEVICE or
PHY_MODE_USB_HOST and then we can set or clear these bits in the ulpi
register space. I think that will make things simpler here and things
like soft-connect will work better. Sound good?
^ permalink raw reply
* [PATCH v2] ARM: imx: gpc: Initialize all power domains
From: Fabio Estevam @ 2016-10-21 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021031116.GG30578@tiger>
Hi Shawn,
On Fri, Oct 21, 2016 at 1:11 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> Thanks for the update. Now we understand that this is a regression
> caused by power domain core change. But my question on why kernel
> crashes with multi_v7_defconfig but not with imx_v6_v7_defconfig stays
> unanswered.
imx_v6_v7_defconfig selects GPU and VPU drivers, which are consumers
of the GPC driver and change the refcount of the pu_reg regulator.
I think we should not continue to boot in case imx_gpc_probe() fails.
So I will send a patch series with this patch and another one that
prevents the boot when imx_gpc_probe() fails.
^ permalink raw reply
* [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Dave Gerlach @ 2016-10-21 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e13cd925-a62d-457d-cc99-fadd4d123256@oracle.com>
On 10/21/2016 02:02 PM, Santosh Shilimkar wrote:
> On 10/21/2016 12:00 PM, Kevin Hilman wrote:
>> Dave Gerlach <d-gerlach@ti.com> writes:
>>
> [...]
>
>>
>> BTW, what is the the status of the TI-SCI protocol drivers themselves?
>> This can't be merged until that is or this won't even compile.
>>
> I was just about to ask the same question.
v4 was sent here which was just a rebase of v3 on v4.9-rc1 with no
changes: http://www.spinics.net/lists/arm-kernel/msg536851.html
Should be ready to merge, just was too late during v4.8 cycle.
Regards,
Dave
>
> Regards,
> Santosh
>
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Marc Zyngier @ 2016-10-21 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <580A60ED.3030307@free.fr>
On Fri, 21 Oct 2016 20:39:41 +0200
Mason <slash.tmp@free.fr> wrote:
> On 21/10/2016 19:46, Marc Zyngier wrote:
>
> > On 21/10/16 17:37, Mason wrote:
> >
> >> On my platform, one HW block pulls the interrupt line high
> >> as long as it remains idle, and low when it is busy.
> >>
> >> The device tree node is:
> >>
> >> test at 22222 {
> >> compatible = "vendor,testme";
> >> interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
> >> };
> >
> > I assume that this is for the sake of the discussion, and that you do
> > not actually intend to put together such a monstrosity.
>
> It's just missing a reg properties to be a valid node, right?
If connecting a device that signals its interrupt as level low to an
input line configured as level high doesn't strike you as a major
issue, nothing will. At that point, you can put anything you want in
your DT.
>
> >> I wrote a minimal driver which registers the irq.
> >> And in the interrupt handler, I disable said irq.
> >>
> >> Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as
> >> it is registered (because the block is idle).
> >>
> >> Here is the code I've been running, request_irq doesn't return.
> >
> > [...]
> >
> >> And here's what I get when I try to load the module:
> >> (I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21)
> >
> > [...]
> >
> >> Are we not supposed to disable the irq in the handler?
> >
> > You can. It then depends on what your interrupt controller does to
> > actually ensure that the interrupt is disabled. Only you can trace it on
> > your HW to find out.
>
> I'm using an upstream driver on v4.9-rc1
>
> http://lxr.free-electrons.com/source/drivers/irqchip/irq-tango.c
>
> Given that the system locks up, is it possible there is a bug
> in the driver?
That's possible.
> Which call-back handles enabling/disabling interrupts?
How about irq_unmask/irq_mask?
Thanks,
M.
--
Jazz is not dead. It just smells funny.
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: Kevin Hilman @ 2016-10-21 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-6-git-send-email-david@lechnology.com>
David Lechner <david@lechnology.com> writes:
> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>
> What is working:
>
> * Pin muxing
> * MicroSD card reader
> * UART on input port 1
>
> What is partially working:
>
> * Buttons - working after GPIO fix
> * LEDs - working after GPIO fix
> * Poweroff/reset - working after GPIO fix
> * Flash memory - driver loads but can't read the block devices - this is
> probably due to the fact that we are not able to configure the SPI to
> use DMA via device tree
> * EEPROM - there seems to be a hardware bug that causes the first byte
> read to be corrupted - this can be worked around by adding an I2C stop
> between writing the register and reading the data, but the at24 driver
> does not have an option to do this
>
> What is not working/to be added later:
>
> * Display - waiting for "tiny DRM" to be mainlined
> * Speaker - needs new PWM sound driver
> * USB - waiting for OHCI and MUSB device tree support to be mainlined
> * ADC - needs new iio driver
> * GPIOs - broken because of recent changes to core gpio driver
> * Bluetooth - needs new driver for sequencing power/enable/clock
> * Input and output ports - need some sort of new phy or extcon driver
> * Battery - needs new power supply driver (depends on ADC iio driver)
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++
nit: can you name this da850-lego-ev3.dts
Though it's not very strictly enforced, we *try* to use the form
<soc>-<board>.dts.
Kevin
^ permalink raw reply
* [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: Andy Shevchenko @ 2016-10-21 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477067879-23750-5-git-send-email-okaya@codeaurora.org>
On Fri, Oct 21, 2016 at 7:37 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> The interrupts can now be delivered as platform MSI interrupts on newer
> platforms. The code looks for a new OF and ACPI strings in order to enable
> the functionality.
> +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
> +static void hidma_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
> +{
> + struct device *dev = msi_desc_to_dev(desc);
> + struct hidma_dev *dmadev = dev_get_drvdata(dev);
> +
> + if (!desc->platform.msi_index) {
> + writel(msg->address_lo, dmadev->dev_evca + 0x118);
> + writel(msg->address_hi, dmadev->dev_evca + 0x11C);
> + writel(msg->data, dmadev->dev_evca + 0x120);
> + }
> +}
> +#endif
> +
> +static void hidma_free_msis(struct hidma_dev *dmadev)
> +{
> +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
Perhaps one #ifdef and two definitions of functions?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Sergio Prado @ 2016-10-21 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021182710.GA17279@kozik-lap>
On Fri, Oct 21, 2016 at 09:27:10PM +0300, Krzysztof Kozlowski wrote:
>
> I acked this twice (v1 and v2)... and still you are ignoring them. I am
> sorry, I am not gonna to ack this third time!
>
> For v2 I acked also other patches but it it is not there as well...
>
> BR,
> Krzysztof
I'm really sorry Krzysztof. This is my first patch series and I didn't
know I should add the acked-by tag to the patches (I thought it would be
done by the maintainer when the patches are accepted/applied).
I'll make sure to do it right next time.
Thanks for taking your time to reviewing and acking my patches.
Best regards,
Sergio Prado
--
Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
^ permalink raw reply
* [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Santosh Shilimkar @ 2016-10-21 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h4m45plxr.fsf@baylibre.com>
On 10/21/2016 12:00 PM, Kevin Hilman wrote:
> Dave Gerlach <d-gerlach@ti.com> writes:
>
[...]
>
> BTW, what is the the status of the TI-SCI protocol drivers themselves?
> This can't be merged until that is or this won't even compile.
>
I was just about to ask the same question.
Regards,
Santosh
^ permalink raw reply
* [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Kevin Hilman @ 2016-10-21 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019203347.17893-4-d-gerlach@ti.com>
Dave Gerlach <d-gerlach@ti.com> writes:
> Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider
> to allow each device to attach and associate it's ti-sci-id so that it can
> be controlled through the TI SCI protocol.
>
> This driver implements a simple genpd where each device node has
> a phandle to the power domain node and also must provide an index which
> represents the ID to be passed with TI SCI representing the device using a
> ti,sci-id property. Through this interface the genpd dev_ops start and
> stop hooks will use TI SCI to turn on and off each device as determined
> by pm_runtime usage.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> MAINTAINERS | 1 +
> arch/arm/mach-keystone/Kconfig | 1 +
> drivers/soc/ti/Kconfig | 12 +++
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++++++++++++++++++
> 5 files changed, 213 insertions(+)
> create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d894873c2bff..3eaac5ede847 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11894,6 +11894,7 @@ F: drivers/firmware/ti_sci*
> F: include/linux/soc/ti/ti_sci_protocol.h
> F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> F: include/dt-bindings/genpd/k2g.h
> +F: drivers/soc/ti/ti_sci_pm_domains.c
>
> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
> M: Hans Verkuil <hverkuil@xs4all.nl>
> diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
> index 24bd64dabdfc..18d49465cafb 100644
> --- a/arch/arm/mach-keystone/Kconfig
> +++ b/arch/arm/mach-keystone/Kconfig
> @@ -9,6 +9,7 @@ config ARCH_KEYSTONE
> select ARCH_SUPPORTS_BIG_ENDIAN
> select ZONE_DMA if ARM_LPAE
> select PINCTRL
> + select PM_GENERIC_DOMAINS if PM
> help
> Support for boards based on the Texas Instruments Keystone family of
> SoCs.
> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
> index 3557c5e32a93..39e152abe6b9 100644
> --- a/drivers/soc/ti/Kconfig
> +++ b/drivers/soc/ti/Kconfig
> @@ -38,4 +38,16 @@ config WKUP_M3_IPC
> to communicate and use the Wakeup M3 for PM features like suspend
> resume and boots it using wkup_m3_rproc driver.
>
> +config TI_SCI_PM_DOMAINS
> + tristate "TI SCI PM Domains Driver"
> + depends on TI_SCI_PROTOCOL
> + depends on PM_GENERIC_DOMAINS
> + help
> + Generic power domain implementation for TI device implementing
> + the TI SCI protocol.
> +
> + To compile this as a module, choose M here. The module will be
> + called ti_sci_pm_domains. Note this is needed early in boot before
> + rootfs may be available.
> +
> endif # SOC_TI
> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
> index 48ff3a79634f..7d572736c86e 100644
> --- a/drivers/soc/ti/Makefile
> +++ b/drivers/soc/ti/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
> +obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
> diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
> new file mode 100644
> index 000000000000..ec76215d64c7
> --- /dev/null
> +++ b/drivers/soc/ti/ti_sci_pm_domains.c
> @@ -0,0 +1,198 @@
> +/*
> + * TI SCI Generic Power Domain Driver
> + *
> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
> + * J Keerthy <j-keerthy@ti.com>
> + * Dave Gerlach <d-gerlach@ti.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program 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.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/slab.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +
> +/**
> + * struct ti_sci_genpd_dev_data: holds data needed for every device attached
> + * to this genpd
> + * @idx: index of the device that identifies it with the system
> + * control processor.
> + */
> +struct ti_sci_genpd_dev_data {
> + int idx;
> +};
If you use #power-domain-cells = <1>, you can drop this...
> +/**
> + * struct ti_sci_pm_domain: TI specific data needed for power domain
> + * @ti_sci: handle to TI SCI protocol driver that provides ops to
> + * communicate with system control processor.
> + * @dev: pointer to dev for the driver for devm allocs
> + * @pd: generic_pm_domain for use with the genpd framework
> + */
> +struct ti_sci_pm_domain {
> + const struct ti_sci_handle *ti_sci;
> + struct device *dev;
> + struct generic_pm_domain pd;
> +};
and add and 'idx' field to this which is populated on attach.
Thank you shouldn't need PATCH 1/4 which adds the new 'void * data'.
Otherwise, the driver looks pretty straight forward.
BTW, what is the the status of the TI-SCI protocol drivers themselves?
This can't be merged until that is or this won't even compile.
Kevin
^ permalink raw reply
* [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Marek Vasut @ 2016-10-21 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021182710.GA17279@kozik-lap>
On 10/21/2016 08:27 PM, Krzysztof Kozlowski wrote:
> On Thu, Oct 20, 2016 at 07:42:44PM -0200, Sergio Prado wrote:
>> Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
>> field in the drivers's platform data structure so it can be selectable
>> via platform data.
>>
>> Also setting this field to NAND_ECC_SOFT in all boards using this
>> driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
>>
>> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
>> ---
>> arch/arm/mach-s3c24xx/common-smdk.c | 1 +
>> arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
>> arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
>> arch/arm/mach-s3c24xx/mach-bast.c | 1 +
>> arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
>> arch/arm/mach-s3c24xx/mach-jive.c | 1 +
>> arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
>> arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
>> arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
>> arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
>> arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
>> arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
>> arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
>> arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
>> arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
>> drivers/mtd/nand/Kconfig | 9 --
>> drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
>> include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
>> 18 files changed, 79 insertions(+), 70 deletions(-)
>>
>
> I acked this twice (v1 and v2)... and still you are ignoring them. I am
> sorry, I am not gonna to ack this third time!
Hi, um, I am kinda new to this mess, what's going on ? You ACKed
previous patches, next revision was submitted, so you need to ACK
the next revision too (due to the changes).
> For v2 I acked also other patches but it it is not there as well...
>
> BR,
> Krzysztof
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Kevin Hilman @ 2016-10-21 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019203347.17893-3-d-gerlach@ti.com>
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
> + 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? ...
> +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>;
Kevin
^ permalink raw reply
* [PATCH 0/5] Support for LEGO MINDSTORTMS EV3
From: Lennart Sorensen @ 2016-10-21 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
On Fri, Oct 21, 2016 at 01:36:52PM -0500, David Lechner wrote:
> This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI AM1808
> based board.
>
> This patch series has been tested working (along with some hacks to fix the
> GPIOs) on an EV3.
>
> There are still quite a few additional new drivers that need to be submitted
> to get everything working. This patch series just adds support for the parts
> that already have mainline kernel drivers.
>
> I have a plan/driver in progress for many of the components[2], but I could use
> some advice on a few particulars.
>
> Bluetooth: This needs a driver to sequence a GPIO to take the Bluetooth chip
> out of shutdown *after* the Bluetooth clock has been configured and started.
> Is there a generic driver that can do this sort of thing? Or, if not, which
> subsystem should the new driver go in?
>
> Input and output ports: These ports are capable of hotplugging various devices,
> such as sensors and motors. I have written a driver for these that can detect
> most devices. I created a new subsystem for this called `lego-port`. However,
> I am wondering if the existing phy or extcon subsystems might be a good fit for
> this sort of thing.
Both this cover and patch 5/5 has MINDSTORTMS instead of MINDSTORMS in
a few places (including the subject line).
--
Len Sorensen
^ permalink raw reply
* Disabling an interrupt in the handler locks the system up
From: Mason @ 2016-10-21 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a79e2d2c-8ec8-744f-50fb-8c39216aa23e@arm.com>
On 21/10/2016 19:46, Marc Zyngier wrote:
> On 21/10/16 17:37, Mason wrote:
>
>> On my platform, one HW block pulls the interrupt line high
>> as long as it remains idle, and low when it is busy.
>>
>> The device tree node is:
>>
>> test at 22222 {
>> compatible = "vendor,testme";
>> interrupts = <23 IRQ_TYPE_LEVEL_HIGH>;
>> };
>
> I assume that this is for the sake of the discussion, and that you do
> not actually intend to put together such a monstrosity.
It's just missing a reg properties to be a valid node, right?
>> I wrote a minimal driver which registers the irq.
>> And in the interrupt handler, I disable said irq.
>>
>> Since the irq is IRQ_TYPE_LEVEL_HIGH, it will fire as soon as
>> it is registered (because the block is idle).
>>
>> Here is the code I've been running, request_irq doesn't return.
>
> [...]
>
>> And here's what I get when I try to load the module:
>> (I'm using the default CONFIG_RCU_CPU_STALL_TIMEOUT=21)
>
> [...]
>
>> Are we not supposed to disable the irq in the handler?
>
> You can. It then depends on what your interrupt controller does to
> actually ensure that the interrupt is disabled. Only you can trace it on
> your HW to find out.
I'm using an upstream driver on v4.9-rc1
http://lxr.free-electrons.com/source/drivers/irqchip/irq-tango.c
Given that the system locks up, is it possible there is a bug
in the driver?
Which call-back handles enabling/disabling interrupts?
Regards.
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
This adds a device tree definition file for LEGO MINDSTORMS EV3.
What is working:
* Pin muxing
* MicroSD card reader
* UART on input port 1
What is partially working:
* Buttons - working after GPIO fix
* LEDs - working after GPIO fix
* Poweroff/reset - working after GPIO fix
* Flash memory - driver loads but can't read the block devices - this is
probably due to the fact that we are not able to configure the SPI to
use DMA via device tree
* EEPROM - there seems to be a hardware bug that causes the first byte
read to be corrupted - this can be worked around by adding an I2C stop
between writing the register and reading the data, but the at24 driver
does not have an option to do this
What is not working/to be added later:
* Display - waiting for "tiny DRM" to be mainlined
* Speaker - needs new PWM sound driver
* USB - waiting for OHCI and MUSB device tree support to be mainlined
* ADC - needs new iio driver
* GPIOs - broken because of recent changes to core gpio driver
* Bluetooth - needs new driver for sequencing power/enable/clock
* Input and output ports - need some sort of new phy or extcon driver
* Battery - needs new power supply driver (depends on ADC iio driver)
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 456 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/lego-ev3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f80f5b7..5f91c1a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -116,7 +116,8 @@ dtb-$(CONFIG_ARCH_CLPS711X) += \
dtb-$(CONFIG_ARCH_DAVINCI) += \
da850-lcdk.dtb \
da850-enbw-cmc.dtb \
- da850-evm.dtb
+ da850-evm.dtb \
+ lego-ev3.dtb
dtb-$(CONFIG_ARCH_DIGICOLOR) += \
cx92755_equinox.dtb
dtb-$(CONFIG_ARCH_EFM32) += \
diff --git a/arch/arm/boot/dts/lego-ev3.dts b/arch/arm/boot/dts/lego-ev3.dts
new file mode 100644
index 0000000..a6b4c7d
--- /dev/null
+++ b/arch/arm/boot/dts/lego-ev3.dts
@@ -0,0 +1,454 @@
+/*
+ * Device tree for LEGO MINDSTORMS EV3
+ *
+ * Copyright (C) 2016 David Lechner <david@lechnology.com>
+ *
+ * This program 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, version 2.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+
+#include "da850.dtsi"
+
+/ {
+ compatible = "lego,ev3", "ti,da850";
+ model = "LEGO MINDSTORMS EV3";
+
+ soc at 1c00000 {
+ /*
+ * (ab)using pinctrl-single to disable all internal pullups/
+ * pulldowns on I/O.
+ */
+ pinmux at 22c00c {
+ compatible = "pinctrl-single";
+ reg = <0x22c00c 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,bit-per-mux;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xf>;
+ /*
+ * There is a bug in pinctrl-single that prevents us
+ * from setting function-mask to 1, so doing things
+ * in groups of 4. Doesn't really matter since we are
+ * disabling all at once anyway.
+ */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pupu_disable>;
+
+ pupu_disable: pinmux_all_pins {
+ pinctrl-single,bits = <
+ 0x0 0x00000000 0xffffffff
+ >;
+ };
+ };
+ };
+
+ /*
+ * The buttons on the EV3 are mapped to keyboard keys.
+ */
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ label = "EV3 buttons";
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>;
+
+ enter {
+ label = "EV3 Button ENTER";
+ linux,code = <KEY_ENTER>;
+ gpios = <&gpio 29 GPIO_ACTIVE_HIGH>;
+ };
+ left {
+ label = "EV3 Button LEFT";
+ linux,code = <KEY_LEFT>;
+ gpios = <&gpio 102 GPIO_ACTIVE_HIGH>;
+ };
+ back {
+ label = "EV3 Button BACK";
+ linux,code = <KEY_BACKSPACE>;
+ gpios = <&gpio 106 GPIO_ACTIVE_HIGH>;
+ };
+ right {
+ label = "EV3 Button RIGHT";
+ linux,code = <KEY_RIGHT>;
+ gpios = <&gpio 124 GPIO_ACTIVE_HIGH>;
+ };
+ down {
+ label = "EV3 Button DOWN";
+ linux,code = <KEY_DOWN>;
+ gpios = <&gpio 126 GPIO_ACTIVE_HIGH>;
+ };
+ up {
+ label = "EV3 Button UP";
+ linux,code = <KEY_UP>;
+ gpios = <&gpio 127 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /*
+ * The EV3 has two built-in bi-color LEDs behind the buttons.
+ */
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ left_red {
+ label = "led1:red:brick-status";
+ /* GP6[13] */
+ gpios = <&gpio 103 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ left_green {
+ label = "led1:green:brick-status";
+ /* GP6[7] */
+ gpios = <&gpio 108 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ right_red {
+ label = "led2:red:brick-status";
+ /* GP6[12] */
+ gpios = <&gpio 109 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ right_green {
+ label = "led2:green:brick-status";
+ /* GP6[14] */
+ gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ /*
+ * The EV3 is powered down by turning off the main 5V supply.
+ */
+ gpio-poweroff {
+ compatible = "gpio-poweroff";
+ /* low signal powers off the board */
+ gpios = <&gpio 107 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&system_power_pin>;
+ };
+
+ /*
+ * The Bluetooth chip requires a clock at 32768Hz. One of the PWMs
+ * is used to generate this signal.
+ */
+ bt-slow-clock {
+ status = "disabled";
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "slow_clk";
+ pwms = <&ecap2 0 30517>;
+ };
+};
+
+&pmx_core {
+ status = "okay";
+
+ spi0_cs3_pin: pinmux_spi0_cs3_pin {
+ pinctrl-single,bits = <
+ /* CS3 */
+ 0xc 0x01000000 0x0f000000
+ >;
+ };
+ mmc0_cd_pin: pinmux_mmc0_cd {
+ pinctrl-single,bits = <
+ /* GP5[14] */
+ 0x2C 0x00000080 0x000000f0
+ >;
+ };
+ button_pins: pinmux_button_pins {
+ pinctrl-single,bits = <
+ /* GP1[13] */
+ 0x8 0x00000800 0x00000f00
+ /* GP6[10] */
+ 0x34 0x00800000 0x00f00000
+ /* GP6[6] */
+ 0x38 0x00000080 0x000000f0
+ /* GP7[12], GP7[14], GP7[15] */
+ 0x40 0x00808800 0x00f0ff00
+ >;
+ };
+ led_pins: pinmux_led_pins {
+ pinctrl-single,bits = <
+ /* GP6[12], GP6[13], GP6[14] */
+ 0x34 0x00008880 0x0000fff0
+ /* GP6[7] */
+ 0x38 0x00000008 0x0000000f
+ >;
+ };
+ system_power_pin: pinmux_system_power {
+ pinctrl-single,bits = <
+ /* GP6[11] */
+ 0x34 0x00080000 0x000f0000
+ >;
+ };
+ in1_pins: pinmux_in1_pins {
+ pinctrl-single,bits = <
+ /* GP0[15] */
+ 0x0 0x00000008 0x0000000f
+ /* GP0[2] */
+ 0x4 0x00800000 0x00f00000
+ /* GP2[2] */
+ 0x18 0x00800000 0x00f00000
+ /* GP8[10], GP8[11] */
+ 0x48 0x88000000 0xff000000
+ >;
+ };
+ in2_pins: pinmux_in2_pins {
+ pinctrl-single,bits = <
+ /* GP0[13], GP0[14] */
+ 0x0 0x00000880 0x00000ff0
+ /* GP8[12], GP8[14], GP8[15] */
+ 0x48 0x00808800 0x00f0ff00
+ >;
+ };
+ in3_pins: pinmux_in3_pins {
+ pinctrl-single,bits = <
+ /* GP0[12] */
+ 0x0 0x00008000 0x0000f000
+ /* GP1[14] */
+ 0x8 0x00000080 0x000000f0
+ /* GP7[11] */
+ 0x40 0x08000000 0x0f000000
+ /* GP7[9] */
+ 0x44 0x00000008 0x0000000f
+ /* GP8[9] */
+ 0x4c 0x00000008 0x0000000f
+ >;
+ };
+ in4_pins: pinmux_in4_pins {
+ pinctrl-single,bits = <
+ /* GP0[1] */
+ 0x4 0x08000000 0x0f000000
+ /* GP1[15] */
+ 0x8 0x00000008 0x0000000f
+ /* GP7[10] */
+ 0x40 0x80000000 0xf0000000
+ /* GP7[8] */
+ 0x44 0x00000080 0x000000f0
+ /* GP6[4] */
+ 0x4c 0x00000800 0x00000f00
+ >;
+ };
+ outa_pins: pinmux_outa_pins {
+ pinctrl-single,bits = <
+ /* GP0[4] */
+ 0x4 0x00008000 0x0000f000
+ /* GP3[15] */
+ 0x1c 0x00000008 0x0000000f
+ /* GP3[6] */
+ 0x20 0x00000080 0x000000f0
+ /* GP5[11] */
+ 0x2c 0x00080000 0x000f0000
+ /* GP5[4] */
+ 0x30 0x00008000 0x0000f000
+ >;
+ };
+ outb_pins: pinmux_outb_pins {
+ pinctrl-single,bits = <
+ /* GP0[3] */
+ 0x4 0x00080000 0x000f0000
+ /* GP2[9] */
+ 0x14 0x08000000 0x0f000000
+ /* GP2[1], GP2[5] */
+ 0x18 0x08000800 0x0f000f00
+ /* GP5[11] */
+ 0x2c 0x80000000 0xf0000000
+ >;
+ };
+ outc_pins: pinmux_outc_pins {
+ pinctrl-single,bits = <
+ /* GP3[8], GP3[14] */
+ 0x1c 0x80000080 0xf00000f0
+ /* GP5[9], GP5[13] */
+ 0x2c 0x08000800 0x0f000f00
+ /* GP6[8] */
+ 0x34 0x80000000 0xf0000000
+ >;
+ };
+ outd_pins: pinmux_outd_pins {
+ pinctrl-single,bits = <
+ /* GP2[8] */
+ 0x14 0x80000000 0xf0000000
+ /* GP5[10], GP5[15] */
+ 0x2c 0x00800008 0x00f0000f
+ /* GP5[3] */
+ 0x30 0x00080000 0x000f0000
+ /* GP6[9] */
+ 0x34 0x08000000 0x0f000000
+ >;
+ };
+ sound_pins: pinmux_sound_pins {
+ pinctrl-single,bits = <
+ /* GP6[15] */
+ 0x34 0x00000008 0x0000000f
+ >;
+ };
+ usb11_pins: pinmux_usb11_pins {
+ pinctrl-single,bits = <
+ /* GP6[5] */
+ 0x40 0x00000080 0x000000f0
+ /* GP6[3] */
+ 0x4c 0x00008000 0x0000f000
+ >;
+ };
+};
+
+/* Input port 2 */
+&serial0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial0_rxtx_pins>;
+};
+
+/* Input port 1 */
+&serial1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial1_rxtx_pins>;
+};
+
+/* Bluetooth */
+&serial2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serial2_rxtx_pins>, <&serial2_rtscts_pins>;
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ /*
+ * EEPROM contains the first stage bootloader, HW ID and Bluetooth MAC.
+ */
+ eeprom at 50 {
+ compatible = "at24,24c128";
+ pagesize = <64>;
+ read-only;
+ reg = <0x50>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ status = "okay";
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 94 GPIO_ACTIVE_LOW>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>, <&mmc0_cd_pin>;
+};
+
+&ehrpwm0 {
+ status = "okay";
+ pinctrl-names = "default";
+ /* SOUND_ARMA */
+ pinctrl-0 = <&ehrpwm0b_pins>;
+};
+
+&ehrpwm1 {
+ status = "disabled";
+ pinctrl-names = "default";
+ /* MBPWM, MAPWM */
+ pinctrl-0 = <&ehrpwm1a_pins>, <&ehrpwm1b_pins>;
+};
+
+&ecap0 {
+ status = "okay";
+ pinctrl-names = "default";
+ /* MCPWM */
+ pinctrl-0 = <&ecap0_pins>;
+};
+
+&ecap1 {
+ status = "disabled";
+ pinctrl-names = "default";
+ /* MDPWM */
+ pinctrl-0 = <&ecap1_pins>;
+};
+
+&ecap2 {
+ status = "disabled";
+ pinctrl-names = "default";
+ /* BTSLOWCLK */
+ pinctrl-0 = <&ecap2_pins>;
+};
+
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>, <&spi0_cs0_pin>, <&spi0_cs3_pin>;
+ dmas = <&edma0 14 0>, <&edma0 15 0>;
+ dma-names = "rx", "tx";
+
+ spi-flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q128a13", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ ti,spi-wdelay = <8>;
+
+ partition at 0 {
+ label = "U-Boot";
+ reg = <0 0x40000>;
+ };
+
+ partition at 40000 {
+ label = "U-Boot Env";
+ reg = <0x40000 0x10000>;
+ };
+
+ partition at 50000 {
+ label = "Kernel";
+ reg = <0x50000 0x200000>;
+ };
+
+ partition at 250000 {
+ label = "Filesystem";
+ reg = <0x250000 0xa50000>;
+ };
+
+ partition at cb0000 {
+ label = "Storage";
+ reg = <0xcb0000 0x2f0000>;
+ };
+ };
+
+ /* TODO: ADC goes here */
+};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
+
+ /* TODO: LCD Display goes here */
+};
+
+&gpio {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] ARM: davinci: enable LEDs default-on trigger in default config
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
The LEDs default-on trigger is nice to have. For example, it can be used
to configure a LED as a power indicator.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 9d7f0bc..e380743 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -181,6 +181,7 @@ CONFIG_LEDS_GPIO=m
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_OMAP=m
CONFIG_DMADEVICES=y
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] ARM: davinci: enable gpio poweroff in default config
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
The gpio-poweroff driver is needed by LEGO MINDSTORMS EV3 (AM1808 based
board).
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 9254609..9d7f0bc 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -117,6 +117,8 @@ CONFIG_SPI_DAVINCI=m
CONFIG_PINCTRL_SINGLE=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_PCA953X=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO=y
CONFIG_WATCHDOG=y
CONFIG_DAVINCI_WATCHDOG=m
CONFIG_MFD_DM355EVM_MSP=y
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] ARM: davinci: Don't append git rev to local version
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
In the davinci default configuration, don't append the git revision to
the local kernel version by. This seems like the more desirable default
value.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index a2f89a3..9254609 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -1,3 +1,4 @@
+# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] ARM: davinci: Compile MMC in kernel
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
This changes the davinci default configuration to compile the davinci
MMC driver into the kernel. This allows booting from an SD card without
requiring an initrd containing the kernel module.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/configs/davinci_all_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 58d04f1..a2f89a3 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -169,9 +169,9 @@ CONFIG_USB_MASS_STORAGE=m
CONFIG_USB_G_SERIAL=m
CONFIG_USB_G_PRINTER=m
CONFIG_USB_CDC_COMPOSITE=m
-CONFIG_MMC=m
+CONFIG_MMC=y
# CONFIG_MMC_BLOCK_BOUNCE is not set
-CONFIG_MMC_DAVINCI=m
+CONFIG_MMC_DAVINCI=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
CONFIG_LEDS_GPIO=m
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] Support for LEGO MINDSTORTMS EV3
From: David Lechner @ 2016-10-21 18:36 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI AM1808
based board.
This patch series has been tested working (along with some hacks to fix the
GPIOs) on an EV3.
There are still quite a few additional new drivers that need to be submitted
to get everything working. This patch series just adds support for the parts
that already have mainline kernel drivers.
I have a plan/driver in progress for many of the components[2], but I could use
some advice on a few particulars.
Bluetooth: This needs a driver to sequence a GPIO to take the Bluetooth chip
out of shutdown *after* the Bluetooth clock has been configured and started.
Is there a generic driver that can do this sort of thing? Or, if not, which
subsystem should the new driver go in?
Input and output ports: These ports are capable of hotplugging various devices,
such as sensors and motors. I have written a driver for these that can detect
most devices. I created a new subsystem for this called `lego-port`. However,
I am wondering if the existing phy or extcon subsystems might be a good fit for
this sort of thing.
[1]: http://mindstorms.lego.com
[2]: https://github.com/ev3dev/lego-linux-drivers/tree/master/evb
David Lechner (5):
ARM: davinci: Compile MMC in kernel
ARM: davinci: Don't append git rev to local version
ARM: davinci: enable gpio poweroff in default config
ARM: davinci: enable LEDs default-on trigger in default config
ARM: dts: Add LEGO MINDSTORTMS EV3 dts
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++
arch/arm/configs/davinci_all_defconfig | 8 +-
3 files changed, 462 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/lego-ev3.dts
--
2.7.4
^ permalink raw reply
* [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Kevin Hilman @ 2016-10-21 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpQwOkXUk8wT6sZ-Ad4XpTnyodK5m24fYJ3P+1QtS0XOA@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On 14 October 2016 at 19:47, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Hi all,
>>
>> Changes since v2 [3] -
>> - Addressed review comments from v2.
>> - domain-idle-states documentation updated
>> - fixed compiler issues with imx driver
>> - minor code change in pm_domains.c
>> - The series is available at [4].
>>
>> Changes since v1 [2] -
>> - Addressed review comments from v1.
>> - Fixes around dynamic allocation of genpd states
>> - Used OF method for iterating phandles
>> - Updated documentation, examples
>> - Rename state variable (provider -> fwnode)
>> - The series is available at [3].
>>
>> The changes from [1] are -
>> - Allocating memory for domain idle states dynamically
>> - Conform to naming conventions for internal and exported genpd functions
>> - DT binding example for domain-idle-state
>> - Use fwnode instead of of_node
>> - Handle atomic case for removal of PM Domain
>> - Rebase on top of Rafael's pm/genpd tree
>>
>> Thanks,
>> Lina
>>
>> Lina Iyer (8):
>> PM / Domains: Make genpd state allocation dynamic
>> PM / Domain: Add residency property to genpd states
>> PM / Domains: Allow domain power states to be read from DT
>> PM / Domains: Save the fwnode in genpd_power_state
>> dt/bindings: Update binding for PM domain idle states
>> PM / Domains: Abstract genpd locking
>> PM / Domains: Support IRQ safe PM domains
>> PM / doc: Update device documentation for devices in IRQ safe PM
>> domains
>>
>> .../devicetree/bindings/power/power_domain.txt | 43 +++
>> Documentation/power/devices.txt | 9 +-
>> arch/arm/mach-imx/gpc.c | 17 +-
>> drivers/base/power/domain.c | 358 +++++++++++++++++----
>> include/linux/pm_domain.h | 28 +-
>> 5 files changed, 383 insertions(+), 72 deletions(-)
>>
>
> Rafael, Lina,
>
> This looks good to me! Unless any other objections, I suggest to apply
> this to get it tested in linux-next.
Looks like it might be a little late now, but anyways
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Krzysztof Kozlowski @ 2016-10-21 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476999766-32526-2-git-send-email-sergio.prado@e-labworks.com>
On Thu, Oct 20, 2016 at 07:42:44PM -0200, Sergio Prado wrote:
> Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
> field in the drivers's platform data structure so it can be selectable
> via platform data.
>
> Also setting this field to NAND_ECC_SOFT in all boards using this
> driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> arch/arm/mach-s3c24xx/common-smdk.c | 1 +
> arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
> arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
> arch/arm/mach-s3c24xx/mach-bast.c | 1 +
> arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
> arch/arm/mach-s3c24xx/mach-jive.c | 1 +
> arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
> arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
> arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
> arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
> arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
> arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
> arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
> arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
> arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
> drivers/mtd/nand/Kconfig | 9 --
> drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
> include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
> 18 files changed, 79 insertions(+), 70 deletions(-)
>
I acked this twice (v1 and v2)... and still you are ignoring them. I am
sorry, I am not gonna to ack this third time!
For v2 I acked also other patches but it it is not there as well...
BR,
Krzysztof
^ permalink raw reply
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-10-21 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7196231.EBkNfFgrcH@wuerfel>
Hi Arnd,
On Wed, Oct 19, 2016 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, October 19, 2016 10:02:57 AM CEST Geert Uytterhoeven wrote:
>> On Mon, Oct 10, 2016 at 4:23 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Tuesday, October 4, 2016 11:09:27 AM CEST Geert Uytterhoeven wrote:
>> >> +static const struct renesas_family fam_rza __initconst = {
>> >> + .name = "RZ/A",
>> >> +};
>> >
>> > I'm not sure about the relationship between this one and the others,
>> > maybe it should be treated in the same way as emev2 and left out from
>> > this driver?
>>
>> While RZ/A doesn't have a version registers (AFAIK), it shares several
>> drivers with the other SoCs (SH/R-Mobile, R-Car).
>> Hence I'd like to keep it, so we can match for it in these drivers when
>> needed. It has e.g. a different variant of the serial port (SCIF), more
>> closely to the one on SH2 rather than SH4.
>
> I'd prefer seeing a separate soc driver for that one.
OK, that can be done.
>> >> +static const struct renesas_family fam_rmobile __initconst = {
>> >> + .name = "R-Mobile",
>> >> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rcar_gen1 __initconst = {
>> >> + .name = "R-Car Gen1",
>> >> + .reg = 0xff000044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rcar_gen2 __initconst = {
>> >> + .name = "R-Car Gen2",
>> >> + .reg = 0xff000044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rcar_gen3 __initconst = {
>> >> + .name = "R-Car Gen3",
>> >> + .reg = 0xfff00044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_rzg __initconst = {
>> >> + .name = "RZ/G",
>> >> + .reg = 0xff000044, /* PRR (Product Register) */
>> >> +};
>> >> +
>> >> +static const struct renesas_family fam_shmobile __initconst = {
>> >> + .name = "SH-Mobile",
>> >> + .reg = 0xe600101c, /* CCCR (Common Chip Code Register) */
>> >> +};
>> >
>> > These seem to fall into two distinct categories, maybe there is a
>> > better way to group them. What device contain the two kinds of
>> > registers (PRR, CCCR)?
>>
>> Actually there are three (notice the extra "f" on R-Car Gen3 ;-)
>
> I see. Hopefully this is just the same register block at a different
> location though.
More or less.
>> Some SoCs have only CCCR, others have only PRR, some have both.
>> On some SoCs one of them can be accessed from the RealTime CPU
>> core (SH) only.
>> On some SoCs the register is not documented, but present.
>> If the PRR exists, it's a better choice, as it contains additional information
>> in the high order bits (representing the presence of each big (CA15/CA57),
>> little (CA7/CA53), and RT (CR7) CPU core). Currently we don't use that
>> information, though.
>>
>> Grouping them in some other way means we would loose the family name,
>> which is exposed through soc_dev_attr->family.
>> The usefulness of family names is debatable though, as this is more an
>> issue of marketing business.
>
> How about having a table to look up the family name by the value
> of the PRR or CCCR then?
Unfortunately there exist SoCs from different families using the same
product ID.
And different SoCs from the same family may have a revision register
or not (e.g. R-Car H1 has, M1A hasn't).
>> > Hardcoding the register address seems rather ugly here, so maybe
>> > there is a way to have two separate probe methods based on the
>> > surrounding register range, and then bind to that?
>>
>> There's no simple relation between CCCR/PRR and other register blocks.
>> I prefer not to add these to DT, as that would add one more worm to the
>> backwards compatibility can.
>
> Hmm, I understand the concern about compatibility with existing DT files,
> but I also really hate to see hardcoded register addresses.
>
> Any reason against requiring the DT node for future chips though?
For future SoCs, we can easily make it mandatory.
> How about this:
>
> The driver could report the hardcoded strings for the SoCs it already
> knows about (you have the table anyway) and not report the revision
> unless there is a regmap containing the CCCR or the PRR, in which
> case you use that. Future SoCs will provide the PRR (I assume
> CCCR is only used on the older ones) through a syscon regmap
> that we can use to find out the exact revision as well.
>
> The existing DT files can gain the syscon device so you can report
> the revision on those machines as well, unless you use an old DTB.
Hmm... That means that if we have to add a driver quirk to distinguish
between different revisions of the same SoC, we have to update the
DTB anyway, to add the CCCR/PRR device node.
We might as well just change the compatible value in that DTB for the
device that needs the quirk. Which is what we'd like to avoid in the
first place.
>> >> +static const struct of_device_id renesas_socs[] __initconst = {
>> >> +#ifdef CONFIG_ARCH_EMEV2
>> >> + { .compatible = "renesas,emev2", .data = &soc_emev2 },
>> >> +#endif
>> >> +#ifdef CONFIG_ARCH_R7S72100
>> >> + { .compatible = "renesas,r7s72100", .data = &soc_rz_a1h },
>> >> +#endif
>> >> +#ifdef CONFIG_ARCH_R8A73A4
>> >
>> > I think the #ifdefs here will result in warnings for unused symbols
>> > when the Kconfig symbols are disabled.
>>
>> Originally I had __maybe_unused, but it didn't seem to be needed.
>> Do you know which compiler needs it, so I can check?
>
> Ah, I remember now: gcc doesn't warn for 'static const' variables
> unless we pass -Wunused-const, which should be enabled with "make W=1",
> and we might make that the default in the future (after fixing the
> handful of drivers currently relying on this).
OK.
> Why not just drop all the #ifdef here? There should be very little
> overhead in size, especially if all the data is __initconst.
It still saves ca. 3 KiB for a kernel for a single SoC.
It's been a while I've tried multi_v7_defconfig, but I'm afraid there's no
Renesas SoC left that can boot it, due to sheer size.
We're facing the same issue with arm64_defconfig soon (it already
fails now if you add a small (1.5 MiB) initrd).
Not to mention RZ/A1H, which is used on some boards running with
its 10 MiB of internal SRAM only.
Kernel size does matter, despite no progress on linux-tiny.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Stephen Boyd @ 2016-10-21 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021021450.GA16461@b29397-desktop>
Quoting Peter Chen (2016-10-20 19:14:50)
>
> I tested my patch, it works well at my side, if it is ok for you, please
> ack it, I will apply it as well as your chipidea series after your
> gpu fix patch at greg's usb-next tree.
Feel free to add my:
Tested-by: Stephen Boyd <stephen.boyd@linaro.org>
Reported-by: Stephen Boyd <stephen.boyd@linaro.org>
tags to the patch.
>
> Is it ok for you?
>
Ok sounds good. The GPU patch has been picked up into drm-misc now, but
I'm not sure if it's going to be merged into -rc2 or not but it sounds
like you'll figure that part out.
I'll resend the phy drivers to Kishon now. Thanks.
^ 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