* [PATCH v2 03/10] dt-bindings: sound: Add new reset compatible for sun4i-i2s
From: Mylene Josserand @ 2017-01-18 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117164636.qhkxvqcs7l732wxk@lukather>
Hi,
On 17/01/2017 17:46, Maxime Ripard wrote:
> On Tue, Jan 17, 2017 at 03:02:23PM +0100, Myl?ne Josserand wrote:
>> Add a new compatible for sun4i-i2s driver to handle some
>> SoCs that have a reset line that must be asserted/deasserted.
>>
>> This new compatible, "allwinner,sun6i-a31-i2s", requires two
>> properties:
>> - resets: phandle to the reset line
>> - reset-names: the name of the reset line ("rst").
>> Except these differences, the compatible is identical to previous one
>> which will not handle a reset line.
>>
>> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
>> ---
>> .../devicetree/bindings/sound/sun4i-i2s.txt | 23 ++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> index 7a2c0945fd22..f673206e309b 100644
>> --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> @@ -7,6 +7,7 @@ Required properties:
>>
>> - compatible: should be one of the following:
>> - "allwinner,sun4i-a10-i2s"
>> + - "allwinner,sun6i-a31-i2s" for controller with reset lines
>
> That's not only for controllers with reset lines, but for the
> controllers found in the A31 (and later). I'd simply drop the last
> part of that line.
ACK
>
>> - reg: physical base address of the controller and length of memory mapped
>> region.
>> - interrupts: should contain the I2S interrupt.
>> @@ -19,7 +20,13 @@ Required properties:
>> - "mod" : module clock for the I2S controller
>> - #sound-dai-cells : Must be equal to 0
>>
>> +Required properties for the following compatibles:
>> + - "allwinner,sun6i-a31-i2s"
>> +- resets: phandle to the reset line for this codec
>> +- reset-names: Contains the reset signal name "rst"
>
> You don't need reset-names if there's a single reset line.
>
ACK
>> +
>> Example:
>> +For "allwinner,sun4i-a10-i2s":
>>
>> i2s0: i2s at 01c22400 {
>> #sound-dai-cells = <0>;
>> @@ -32,3 +39,19 @@ i2s0: i2s at 01c22400 {
>> <&dma SUN4I_DMA_NORMAL 3>;
>> dma-names = "rx", "tx";
>> };
>> +
>> +For "allwinner,sun6i-a31-i2s":
>> +
>> +dai: dai at 01c22c00 {
>> + #sound-dai-cells = <0>;
>> + compatible = "allwinner,sun6i-a31-i2s";
>> + reg = <0x01c22c00 0x200>;
>> + interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
>> + clock-names = "apb", "mod";
>> + resets = <&ccu RST_BUS_CODEC>;
>> + reset-names = "rst";
>> + dmas = <&dma 15>, /* AUDIO_CODEC port */
>> + <&dma 15>; /* AUDIO_CODEC port */
>> + dma-names = "rx", "tx";
>> +};
>
> And we already have an example, so there's no need to add a new one
> either.
I will remove it on a V3.
Thank you the review!
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 07/10] dt-bindings: sound: Add sun8i audio documentation
From: Mylene Josserand @ 2017-01-18 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117165029.wu4m6flhdwxk5e3q@sirena.org.uk>
Hi,
On 17/01/2017 17:50, Mark Brown wrote:
> On Tue, Jan 17, 2017 at 03:02:27PM +0100, Myl?ne Josserand wrote:
>> Add the documentation for dt-binding of the digital audio codec driver
>> and the audio card driver for Sun8i SoCs.
>
>
> Please submit patches using subject lines reflecting the style for the
> subsystem. This makes it easier for people to identify relevant
> patches. Look at what existing commits in the area you're changing are
> doing and make sure your subject lines visually resemble what they're
> doing.
>
Yeah, sorry about that. Maxime indicated it in another patch. I will
keep it in mind for next times.
Anyway, thank you for the review!
Best regards,
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 01/13] soc: samsung: pmu: Provide global function to get PMU regmap
From: Tomasz Figa @ 2017-01-18 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-2-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
2017-01-17 21:44 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
> PMU is something like a SoC wide service, so add a helper function to get
> PMU regmap. This will be used by other Exynos device drivers. This way it
> can be avoided to model this dependency in device tree (as phandles to PMU
> node) for almost every device in the SoC.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/soc/samsung/exynos-pmu.c | 11 +++++++++++
> include/linux/soc/samsung/exynos-pmu.h | 7 +++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
> index 0acdfd82e751..5c269bf23210 100644
> --- a/drivers/soc/samsung/exynos-pmu.c
> +++ b/drivers/soc/samsung/exynos-pmu.c
> @@ -11,6 +11,7 @@
>
> #include <linux/of.h>
> #include <linux/of_address.h>
> +#include <linux/mfd/syscon.h>
> #include <linux/platform_device.h>
> #include <linux/delay.h>
>
> @@ -92,6 +93,16 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
> { /*sentinel*/ },
> };
>
> +struct regmap *exynos_get_pmu_regmap(void)
> +{
> + struct device_node *np = of_find_matching_node(NULL,
> + exynos_pmu_of_device_ids);
> + if (np)
> + return syscon_node_to_regmap(np);
> + return ERR_PTR(-ENODEV);
> +}
> +EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap);
> +
> static int exynos_pmu_probe(struct platform_device *pdev)
> {
> const struct of_device_id *match;
> diff --git a/include/linux/soc/samsung/exynos-pmu.h b/include/linux/soc/samsung/exynos-pmu.h
> index e2e9de1acc5b..2a841a474684 100644
> --- a/include/linux/soc/samsung/exynos-pmu.h
> +++ b/include/linux/soc/samsung/exynos-pmu.h
> @@ -12,6 +12,8 @@
> #ifndef __LINUX_SOC_EXYNOS_PMU_H
> #define __LINUX_SOC_EXYNOS_PMU_H
>
> +#include <linux/regmap.h>
> +
nit: It would save some compilation time to just add a forward
declaration of struct regmap here instead, in case of files that
include this header, but don't need regmap functionality.
> enum sys_powerdown {
> SYS_AFTR,
> SYS_LPA,
> @@ -20,5 +22,10 @@ enum sys_powerdown {
> };
>
> extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
> +#ifdef CONFIG_EXYNOS_PMU
> +extern struct regmap *exynos_get_pmu_regmap(void);
> +#else
> +static inline struct regmap *exynos_get_pmu_regmap(void) { return NULL; }
Shouldn't be some ERR_PTR() instead?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v8 12/18] irqdomain: Add irq domain MSI and MSI_REMAP flags
From: Tomasz Nowicki @ 2017-01-18 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484127714-3263-13-git-send-email-eric.auger@redhat.com>
On 11.01.2017 10:41, Eric Auger wrote:
> We introduce two new enum values for the irq domain flag:
> - IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to
> an MSI domain
> - IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI
> remapping capabilities.
>
> Those values will be useful to check all MSI irq domains have
> MSI remapping support when assessing the safety of IRQ assignment
> to a guest.
>
> irq_domain_hierarchical_is_msi_remap() allows to check if an
> irq domain or any parent implements MSI remapping.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
>
> ---
>
> v7 -> v8:
> - remove h variable in irq_domain_hierarchical_is_msi_remap
> - add Marc's R-b
>
> v6:
> - add IRQ_DOMAIN_FLAG_MSI as suggested by Marc
> - add irq_domain_is_msi, irq_domain_is_msi_remap and
> irq_domain_hierarchical_is_msi_remap
> ---
> include/linux/irqdomain.h | 35 +++++++++++++++++++++++++++++++++++
> kernel/irq/irqdomain.c | 14 ++++++++++++++
> 2 files changed, 49 insertions(+)
>
> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
> index ffb8460..bc2f571 100644
> --- a/include/linux/irqdomain.h
> +++ b/include/linux/irqdomain.h
> @@ -183,6 +183,12 @@ enum {
> /* Irq domain is an IPI domain with single virq */
> IRQ_DOMAIN_FLAG_IPI_SINGLE = (1 << 3),
>
> + /* Irq domain implements MSIs */
> + IRQ_DOMAIN_FLAG_MSI = (1 << 4),
> +
> + /* Irq domain implements MSI remapping */
> + IRQ_DOMAIN_FLAG_MSI_REMAP = (1 << 5),
> +
> /*
> * Flags starting from IRQ_DOMAIN_FLAG_NONCORE are reserved
> * for implementation specific purposes and ignored by the
> @@ -446,6 +452,19 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
> {
> return domain->flags & IRQ_DOMAIN_FLAG_IPI_SINGLE;
> }
> +
> +static inline bool irq_domain_is_msi(struct irq_domain *domain)
> +{
> + return domain->flags & IRQ_DOMAIN_FLAG_MSI;
> +}
> +
> +static inline bool irq_domain_is_msi_remap(struct irq_domain *domain)
> +{
> + return domain->flags & IRQ_DOMAIN_FLAG_MSI_REMAP;
> +}
> +
> +extern bool irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain);
> +
> #else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
> static inline void irq_domain_activate_irq(struct irq_data *data) { }
> static inline void irq_domain_deactivate_irq(struct irq_data *data) { }
> @@ -477,6 +496,22 @@ static inline bool irq_domain_is_ipi_single(struct irq_domain *domain)
> {
> return false;
> }
> +
> +static inline bool irq_domain_is_msi(struct irq_domain *domain)
> +{
> + return false;
> +}
> +
> +static inline bool irq_domain_is_msi_remap(struct irq_domain *domain)
> +{
> + return false;
> +}
> +
> +static inline bool
> +irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain)
> +{
> + return false;
> +}
> #endif /* CONFIG_IRQ_DOMAIN_HIERARCHY */
>
> #else /* CONFIG_IRQ_DOMAIN */
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index 8c0a0ae..876e131 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -1392,6 +1392,20 @@ static void irq_domain_check_hierarchy(struct irq_domain *domain)
> if (domain->ops->alloc)
> domain->flags |= IRQ_DOMAIN_FLAG_HIERARCHY;
> }
> +
> +/**
> + * irq_domain_hierarchical_is_msi_remap - Check if the domain or any
> + * parent has MSI remapping support
> + * @domain: domain pointer
> + */
> +bool irq_domain_hierarchical_is_msi_remap(struct irq_domain *domain)
> +{
> + for (; domain; domain = domain->parent) {
> + if (irq_domain_is_msi_remap(domain))
> + return true;
> + }
> + return false;
> +}
> #else /* CONFIG_IRQ_DOMAIN_HIERARCHY */
> /**
> * irq_domain_get_irq_data - Get irq_data associated with @virq and @domain
>
^ permalink raw reply
* [PATCH v2 10/13] pinctrl: samsung: Add infrastructure for pin-bank retention control
From: Tomasz Figa @ 2017-01-18 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-11-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
2017-01-17 21:44 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
> Pad retention control after suspend/resume cycle should be done from pin
> controller driver instead of PMU (power management unit) driver to avoid
> possible ordering and logical dependencies. Till now it worked fine only
> because PMU driver registered its sys_ops after pin controller.
>
> This patch adds infrastructure to handle pad retention during pin control
> driver resume.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> drivers/pinctrl/samsung/pinctrl-samsung.c | 12 +++++++++
> drivers/pinctrl/samsung/pinctrl-samsung.h | 42 +++++++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
> index 59f99ea7e65b..021abd7221f8 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.c
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
> @@ -1060,6 +1060,13 @@ static int samsung_pinctrl_probe(struct platform_device *pdev)
> if (res)
> drvdata->irq = res->start;
>
> + if (ctrl->retention_data) {
> + drvdata->retention_ctrl = ctrl->retention_data->init(drvdata,
> + ctrl->retention_data);
> + if (IS_ERR(drvdata->retention_ctrl))
> + return PTR_ERR(drvdata->retention_ctrl);
> + }
> +
> ret = samsung_gpiolib_register(pdev, drvdata);
> if (ret)
> return ret;
> @@ -1126,6 +1133,8 @@ static void samsung_pinctrl_suspend_dev(
>
> if (drvdata->suspend)
> drvdata->suspend(drvdata);
> + if (drvdata->retention_ctrl && drvdata->retention_ctrl->enable)
> + drvdata->retention_ctrl->enable(drvdata);
Do we need to check presence of ->enable? I think it doesn't make much
sense to provide retention_ctrl with NULL enable or disable.
> }
>
> /**
> @@ -1173,6 +1182,9 @@ static void samsung_pinctrl_resume_dev(struct samsung_pinctrl_drv_data *drvdata)
> if (widths[type])
> writel(bank->pm_save[type], reg + offs[type]);
> }
> +
> + if (drvdata->retention_ctrl && drvdata->retention_ctrl->disable)
> + drvdata->retention_ctrl->disable(drvdata);
Ditto.
> }
>
> /**
> diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
> index 6f7ce7539a00..5ebbf4137a06 100644
> --- a/drivers/pinctrl/samsung/pinctrl-samsung.h
> +++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
> @@ -185,10 +185,48 @@ struct samsung_pin_bank {
> };
>
> /**
> + * struct samsung_retention_data: runtime pin-bank retention control data.
> + * @regs: array of PMU registers to control pad retention.
> + * @nr_regs: number of registers in @regs array.
> + * @value: value to store to registers to turn off retention.
> + * @refcnt: atomic counter if retention control affects more than one bank.
> + * @priv: retention control code private data
> + * @on: platform specific callback to enter retention mode.
> + * @off: platform specific callback to exit retention mode.
s/on/enable/ and s/off/disable/ in comments too. Thanks for taking my
bikeshedding into account, though. :)
> + **/
> +struct samsung_retention_ctrl {
> + const u32 *regs;
> + int nr_regs;
> + u32 value;
> + atomic_t *refcnt;
> + void *priv;
> + void (*enable)(struct samsung_pinctrl_drv_data *);
> + void (*disable)(struct samsung_pinctrl_drv_data *);
^^
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v8 13/18] genirq/msi: Set IRQ_DOMAIN_FLAG_MSI on MSI domain creation
From: Tomasz Nowicki @ 2017-01-18 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484127714-3263-14-git-send-email-eric.auger@redhat.com>
On 11.01.2017 10:41, Eric Auger wrote:
> Now we have a flag value indicating an IRQ domain implements MSI,
> let's set it on msi_create_irq_domain().
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
>
> ---
>
> v7 -> v8
> - Added Marc's R-b
>
> v6: new
> ---
> kernel/irq/msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
> index ee23006..ddc2f54 100644
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -270,8 +270,8 @@ struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode,
> if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
> msi_domain_update_chip_ops(info);
>
> - return irq_domain_create_hierarchy(parent, 0, 0, fwnode,
> - &msi_domain_ops, info);
> + return irq_domain_create_hierarchy(parent, IRQ_DOMAIN_FLAG_MSI, 0,
> + fwnode, &msi_domain_ops, info);
> }
>
> int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
>
^ permalink raw reply
* [PATCH v8 14/18] irqdomain: irq_domain_check_msi_remap
From: Tomasz Nowicki @ 2017-01-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5eb6945b-9d4c-9521-1d5d-10eba633fd59@caviumnetworks.com>
On 17.01.2017 15:06, Tomasz Nowicki wrote:
> On 17.01.2017 14:53, Auger Eric wrote:
>> Hi Tomasz,
>>
>> On 17/01/2017 14:40, Tomasz Nowicki wrote:
>>> On 11.01.2017 10:41, Eric Auger wrote:
>>>> This new function checks whether all MSI irq domains
>>>> implement IRQ remapping. This is useful to understand
>>>> whether VFIO passthrough is safe with respect to interrupts.
>>>>
>>>> On ARM typically an MSI controller can sit downstream
>>>> to the IOMMU without preventing VFIO passthrough.
>>>> As such any assigned device can write into the MSI doorbell.
>>>> In case the MSI controller implements IRQ remapping, assigned
>>>> devices will not be able to trigger interrupts towards the
>>>> host. On the contrary, the assignment must be emphasized as
>>>> unsafe with respect to interrupts.
>>>>
>>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>>> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> ---
>>>> v7 -> v8:
>>>> - remove goto in irq_domain_check_msi_remap
>>>> - Added Marc's R-b
>>>>
>>>> v5 -> v6:
>>>> - use irq_domain_hierarchical_is_msi_remap()
>>>> - comment rewording
>>>>
>>>> v4 -> v5:
>>>> - Handle DOMAIN_BUS_FSL_MC_MSI domains
>>>> - Check parents
>>>> ---
>>>> include/linux/irqdomain.h | 1 +
>>>> kernel/irq/irqdomain.c | 22 ++++++++++++++++++++++
>>>> 2 files changed, 23 insertions(+)
>>>>
>>>> diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
>>>> index bc2f571..188eced 100644
>>>> --- a/include/linux/irqdomain.h
>>>> +++ b/include/linux/irqdomain.h
>>>> @@ -222,6 +222,7 @@ struct irq_domain *irq_domain_add_legacy(struct
>>>> device_node *of_node,
>>>> void *host_data);
>>>> extern struct irq_domain *irq_find_matching_fwspec(struct irq_fwspec
>>>> *fwspec,
>>>> enum irq_domain_bus_token bus_token);
>>>> +extern bool irq_domain_check_msi_remap(void);
>>>> extern void irq_set_default_host(struct irq_domain *host);
>>>> extern int irq_domain_alloc_descs(int virq, unsigned int nr_irqs,
>>>> irq_hw_number_t hwirq, int node,
>>>> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
>>>> index 876e131..d889751 100644
>>>> --- a/kernel/irq/irqdomain.c
>>>> +++ b/kernel/irq/irqdomain.c
>>>> @@ -278,6 +278,28 @@ struct irq_domain
>>>> *irq_find_matching_fwspec(struct irq_fwspec *fwspec,
>>>> EXPORT_SYMBOL_GPL(irq_find_matching_fwspec);
>>>>
>>>> /**
>>>> + * irq_domain_check_msi_remap - Check whether all MSI
>>>> + * irq domains implement IRQ remapping
>>>> + */
>>>> +bool irq_domain_check_msi_remap(void)
>>>> +{
>>>> + struct irq_domain *h;
>>>> + bool ret = true;
>>>> +
>>>> + mutex_lock(&irq_domain_mutex);
>>>> + list_for_each_entry(h, &irq_domain_list, link) {
>>>> + if (irq_domain_is_msi(h) &&
>>>> + !irq_domain_hierarchical_is_msi_remap(h)) {
>>>> + ret = false;
>>>> + break;
>>>> + }
>>>> + }
>>>> + mutex_unlock(&irq_domain_mutex);
>>>> + return ret;
>>>> +}
>>>
>>> Above function returns true, even though there is no MSI irq domains. Is
>>> it intentional ?
>> From the VFIO integration point of view this is what we want. If there
>> is no MSI controller in the system, we have no vulnerability with
>> respect to IRQ assignment and we consider the system as safe. If
>> requested I can add a comment?
>>
>
> I see. Yes, a comment would be helpful then :) Thanks!
>
Anyway:
Reviewed-by: Tomasz Nowicki <tomasz.nowicki@caviumnetworks.com>
Thanks,
Tomasz
^ permalink raw reply
* [PATCH v2 00/13] Move pad retention control to Exynos pin controller driver
From: Tomasz Figa @ 2017-01-18 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484657084-26227-1-git-send-email-m.szyprowski@samsung.com>
Hi Marek,
2017-01-17 21:44 GMT+09:00 Marek Szyprowski <m.szyprowski@samsung.com>:
> Changelog:
>
> v2:
> - reworked exynos_get_pmu_regmap() function and moved to Exynos PMU driver,
> now it doesn't depend on driver probe order thus doesn't need to defer probing
> of pinctrl driver if PMU has not yet been probed
> - collected Acks, minor fixes according to review comments
After fixing remaining nits in patch 1 and 10, for all pinctrl patches (4-13):
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
and for other patches (1-3):
Reviewed-by: Tomasz Figa <tomasz.figa@gmail.com>
Best regards,
Tomasz
^ permalink raw reply
* [PATCH RFC 0/5] mvebu cleanups and preparation for Armada 7k/8k
From: Linus Walleij @ 2017-01-18 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170113112829.GP14217@n2100.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:28 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Fri, Jan 13, 2017 at 11:02:40AM +0000, Russell King - ARM Linux wrote:
>> (Resend including linux-arm-kernel)
>
> BTW, would be useful if MAINTAINERS could list maintainers for both
> this code and the mvebu gpio code too. At the moment, it seems Linus
> is the person responsible for both of those - but I suspect the mvebu
> people want to be copied on patches...
Agreed. Since they are silent I will likely simply apply the patches,
they certainly look good to me.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 1/5] pinctrl: mvebu: constify mvebu_mpp_ctrl structures
From: Linus Walleij @ 2017-01-18 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdb-0002YP-8q@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> As the mvebu_mpp_ctrl structures contain function pointers, it is
> preferable for these to be made read-only to prevent the function
> pointers being modified. So make these const.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 2/5] pinctrl: mvebu: provide per-control private data
From: Linus Walleij @ 2017-01-18 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdg-0002YX-D7@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Provide per-control private data into each mvebu pinctrl method, which
> will allow us to provide some completely generic helpers without the
> global variable and per-instance function definitions that would be
> required when we have multiple pin controllers on a SoC.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 4/5] pinctrl: mvebu: switch drivers to generic simple mmio
From: Linus Walleij @ 2017-01-18 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdq-0002Yl-Lv@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Move the mvebu pinctrl drivers over to the generic simple mmio
> implementation, saving a substantial number of lines of code in
> the process.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Very nice patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC 5/5] pinctrl: mvebu: add simple regmap based pinctrl implementation
From: Linus Walleij @ 2017-01-18 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1cRzdv-0002Ys-Pe@rmk-PC.armlinux.org.uk>
On Fri, Jan 13, 2017 at 12:03 PM, Russell King
<rmk+kernel@armlinux.org.uk> wrote:
> Add a simple regmap based pinctrl implementation for mvebu, for syscon
> based regmap drivers.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 06/14] ARM: davinci: da850: model the SATA refclk
From: Sekhar Nori @ 2017-01-18 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655976-25382-7-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 17 January 2017 05:56 PM, Bartosz Golaszewski wrote:
> Register a dummy clock modelling the external SATA oscillator for
I would not call it a dummy clock. Its representing something physically
present. Just call it "fixed rate clock" ?
> da850 DT mode. For non-DT boot we don't register the clock - instead
> we rely on the default MPY value defined in the da850 ahci driver (as
> is done currently).
Here too, like David suggested, it will be nice to register it both for
DT and non-DT case. With that I think your driver will be simple too
since you dont have to worry about the case when refclkpn is not supplied.
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/da8xx-dt.c | 8 ++++++++
> arch/arm/mach-davinci/devices-da8xx.c | 23 +++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
> 3 files changed, 32 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index b83e5d1..13137cb 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -61,6 +61,14 @@ static void __init da850_init_machine(void)
> pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
> __func__, ret);
>
> + if (of_machine_is_compatible("ti,da850-evm") ||
> + of_machine_is_compatible("ti,da850-lcdk")) {
> + ret = da850_register_sata_refclk(100000000);
> + if (ret)
> + pr_warn("%s: registering SATA_REFCLK clock failed: %d",
> + __func__, ret);
> + }
Since all supported boards use 100 Mhz refclk anyway, I would drop the
machine check and just do:
/* All existing boards use 100MHz SATA refclkpn */
unsigned long sata_refclkpn = 100 * 1000 * 1000;
ret = da850_register_sata_refclk(sata_refclkpn);
It should then be easy for the odd board (when it comes) to set
sata_refclkpn to a different value.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 01/14] devicetree: bindings: add bindings for ahci-da850
From: Sekhar Nori @ 2017-01-18 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e3c8946-2a19-3e11-c071-b3737554005c@lechnology.com>
On Wednesday 18 January 2017 12:05 AM, David Lechner wrote:
> On 01/17/2017 06:26 AM, Bartosz Golaszewski wrote:
>> Add DT bindings for the TI DA850 AHCI SATA controller.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> Documentation/devicetree/bindings/ata/ahci-da850.txt | 18
>> ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> new file mode 100644
>> index 0000000..e7111b4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> @@ -0,0 +1,18 @@
>> +Device tree binding for the TI DA850 AHCI SATA Controller
>> +---------------------------------------------------------
>> +
>> +Required properties:
>> + - compatible: must be "ti,da850-ahci"
>> + - reg: physical base addresses and sizes of the controller's
>> register areas
>> + - interrupts: interrupt specifier (refer to the interrupt binding)
>> +
>> +Optional properties:
>> + - clocks: clock specifier (refer to the common clock binding)
>
> Won't you also need a clock-names property since there are two clocks?
>
>> +
>> +Example:
>> +
>> + sata: ahci at 218000 {
>> + compatible = "ti,da850-ahci";
>> + reg = <0x218000 0x2000>, <0x22c018 0x4>;
>> + interrupts = <67>;
>> + };
>>
>
> It would be nice to have clocks and clock-names in the example as well.
Well, we don't use the common clock binding today. Is it really
necessary to add them now. Thats basically going to remain completely
untested.
I would drop the mention of clocks specification as an optional property
too.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Thierry Reding @ 2017-01-18 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483608344-9012-4-git-send-email-benjamin.gaignard@st.com>
On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..866f222
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,33 @@
> +STMicroelectronics STM32 Timers PWM bindings
> +
> +Must be a sub-node of an STM32 Timers device tree node.
> +See ../mfd/stm32-timers.txt for details about the parent node.
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm".
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> +
> +Optional parameters:
> +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> + "index" indicates on which break input the configuration should be applied.
It might be useful to specify what the valid values are for the break
input index.
Also, u32 is kind of a Linuxism, perhaps "Arrays of three cells"? Also,
does this mean there can be multiple entries? Such as 6 cells for two
configurations? What's the maximum number of such configurations?
If it's possible to specify multiple configurations, maybe a slightly
clearer wording would be: "One or more <index level filter> triplets to
describe..."
> + "level" gives the active level (0=low or 1=high) for this configuration.
So how does this work exactly? "level" specifies the output level if the
filter value is matched?
> + "filter" gives the filtering value to be applied.
Is this a single value at which "level" will be applied? Or is it an
upper/lower bound that can be used to restrict the output to "level" if
the signal goes beyond/below a certain threshold?
Maybe an example would clarify this. Or perhaps a reference to a manual
where a more in-depth description of this functionality can be found.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170118/45afc3e2/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: DT: STiH407: Add RTS / CTS pinctrl definition for UARTs.
From: Lee Jones @ 2017-01-18 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484671615-16343-1-git-send-email-peter.griffin@linaro.org>
Couple of nits and a question.
On Tue, 17 Jan 2017, Peter Griffin wrote:
> The uart IP is capable of doing hardware flow control. Define
UART
> the RTS and CTS pins for STiH407 family Socs so we can use this
SoCs
> feature in the future if we wish to.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> arch/arm/boot/dts/stih407-pinctrl.dtsi | 50 ++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> index daab16b..3bbb0c0 100644
> --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
> @@ -149,6 +149,16 @@
> rx = <&pio3 5 ALT1 IN>;
> };
> };
> + pinctrl_sbc_serial0_rts: sbc_serial0-0_rts {
> + st,pins {
> + rts = <&pio3 7 ALT1 OUT>;
> + };
> + };
> + pinctrl_sbc_serial0_cts: sbc_serial0-0_cts {
> + st,pins {
> + cts = <&pio3 6 ALT1 IN>;
> + };
> + };
Basic premise looks good, but why have you separated the lines?
I believe they are used together when HW flow-control is enabled.
> };
> /* SBC_ASC1 - UART11 */
> sbc_serial1 {
> @@ -158,6 +168,16 @@
> rx = <&pio2 7 ALT3 IN>;
> };
> };
> + pinctrl_sbc_serial1_rts: sbc_serial1-0_rts {
> + st,pins {
> + rts = <&pio3 1 ALT3 OUT>;
> + };
> + };
> + pinctrl_sbc_serial1_cts: sbc_serial1-0_cts {
> + st,pins {
> + cts = <&pio3 0 ALT3 IN>;
> + };
> + };
> };
>
> i2c10 {
> @@ -469,6 +489,16 @@
> rx = <&pio17 1 ALT1 IN>;
> };
> };
> + pinctrl_serial0_rts: serial0-0_rts {
> + st,pins {
> + rts = <&pio17 3 ALT1 OUT>;
> + };
> + };
> + pinctrl_serial0_cts: serial0-0_cts {
> + st,pins {
> + cts = <&pio17 2 ALT1 IN>;
> + };
> + };
> };
>
> serial1 {
> @@ -478,6 +508,16 @@
> rx = <&pio16 1 ALT1 IN>;
> };
> };
> + pinctrl_serial1_rts: serial1-0_rts {
> + st,pins {
> + rts = <&pio16 3 ALT1 OUT>;
> + };
> + };
> + pinctrl_serial1_cts: serial1-0_cts {
> + st,pins {
> + cts = <&pio16 2 ALT1 IN>;
> + };
> + };
> };
>
> serial2 {
> @@ -487,6 +527,16 @@
> rx = <&pio15 1 ALT1 IN>;
> };
> };
> + pinctrl_serial2_rts: serial2-0_rts {
> + st,pins {
> + rts = <&pio15 3 ALT1 OUT>;
> + };
> + };
> + pinctrl_serial2_cts: serial2-0_cts {
> + st,pins {
> + cts = <&pio15 2 ALT1 IN>;
> + };
> + };
> };
>
> mmc1 {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 2/3] spi: pxa2xx: Prepare for edge-triggered interrupts
From: Jan Kiszka @ 2017-01-18 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r340eq28.fsf@belgarion.home>
On 2017-01-18 09:21, Robert Jarzmik wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
>
>> On 2017-01-17 08:54, Robert Jarzmik wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> When using the a device with edge-triggered interrupts, such as MSIs,
>>>> the interrupt handler has to ensure that there is a point in time during
>>>> its execution where all interrupts sources are silent so that a new
>>>> event can trigger a new interrupt again.
>>>>
>>>> This is achieved here by looping over SSSR evaluation. We need to take
>>>> into account that SSCR1 may be changed by the transfer handler, thus we
>>>> need to redo the mask calculation, at least regarding the volatile
>>>> interrupt enable bit (TIE).
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> Hi Jan,
>>>
>>>> + while (1) {
>>> This bit worries me a bit, as this can be either :
>>> - hogging the SoC's CPU, endlessly running
>>> - or even worse, blocking the CPU for ever
>>>
>>> The question behind is, should this be done in a top-half, or moved to a irq
>>> thread ?
>>
>> Every device with a broken interrupt source can hog CPUs, nothing
>> special with this one. If you don't close the loop in the handler
>> itself, you close it over the hardware retriggering the interrupt over
>> and over again.
> I'm not speaking of a broken interrupt source, I'm speaking of a broken code,
> such as in the handler, or broken status readback, or lack of understanding on
> the status register which may imply the while(1) to loop forever.
>
>> So, I don't see a point in offloading to a thread. The normal case is
>> some TX done (FIFO available) event followed by an RX event, then the
>> transfer is complete, isn't it?
> The point is if you stay forever in the while(1) loop, you can at least have a
> print a backtrace (LOCKUP_DETECTOR).
I won't consider "debugability" as a good reason to move interrupt
handlers into threads. There should be real workload that requires
offloading or specific prioritization.
>
>>> Imagine that on first iteration the handler returns IRQ_NONE, and on second
>>> IRQ_HANDLED. This makes ret IRQ_HANDLED. Yet after the first iteration the
>>> handler should have exited, especially if the interrupt is shared with another
>>> driver.
>>
>> That would be a bug in transfer_handler, because we don't enter it
>> without a reason (status != 0).
> Sure, but can you be sure that all the people modifying the code after you will
> see that also ? The other way will _force_ them to see it.
>
>>> Another thing which is along what Andy already said : it would be better
>>> practice to have this loop in the form :
>>> do {
>>> ...
>>> } while (exit_condition_not_met);
>>
>> This implies code duplication in order to calculate the condition
>> (mask...). I can do this if desired, I wouldn't do this to my own code,
>> though.
> Okay, that's acceptable.
> Why not have something like this :
>
> sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
> if (!(sccr1_reg & SSCR1_TIE))
> mask &= ~SSSR_TFS;
>
> /* Ignore RX timeout interrupt if it is disabled */
> if (!(sccr1_reg & SSCR1_TINTE))
> mask &= ~SSSR_TINT;
>
> status = pxa2xx_spi_read(drv_data, SSR);
> while (status & mask) {
> ... handlers etc ...
> status = pxa2xx_spi_read(drv_data, SSR);
> };
>
> There is a duplication of the status read, but that looks acceptable, and the
> mask calculation is moved out of the loop (this should be checked more
> thoroughly as it looked to me only probe() would change these values, yet I
> might be wrong).
Unfortunately, mask can change if SSCR1_TIE is cleared. So this is not
correct.
What would be an alternative to looping is masking (would be required
for threaded irq anyway - but then we won't need to loop in the first
place): disable all irq sources, check the status bits once, re-enable
according to a potentially updated set, leave the handler and let the
hardware call us again.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH 2/3] Documentation: devicetree: amlogic: Add R-Box Pro
From: Neil Armstrong @ 2017-01-18 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170117225459.4438-2-afaerber@suse.de>
On 01/17/2017 11:54 PM, Andreas F?rber wrote:
> Cc: ada at kingnoval.com
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
> ---
> Originally I thought we would group by SoC (6, 8, 8b, gxbb, gxl, gmx, etc.)
> but this got out of order with nexbox,a95x - so inserting kingnovel between
> amlogic and nexbox here. If that's what we want going forward, we should move
> the old entries to make the scheme clearer. The alternative would be to
> reorder alphabetically within each SoC group, but nexbox,a95x with two SoCs
> makes it difficult to categorize, we could choose gxbb as the earlier one.
Andreas,
Feel free to provide a fixup.
Neil
>
> Documentation/devicetree/bindings/arm/amlogic.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index 9b2b41ab6817..fb0ee7d9a921 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -45,5 +45,6 @@ Board compatible values:
> - "amlogic,p231" (Meson gxl s905d)
> - "amlogic,q200" (Meson gxm s912)
> - "amlogic,q201" (Meson gxm s912)
> + - "kingnovel,r-box-pro" (Meson gxm S912)
> - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> - "nexbox,a1" (Meson gxm s912)
>
^ permalink raw reply
* [PATCH] [media] s5p-mfc: Align stream buffer and CPB buffer to 512
From: Smitha T Murthy @ 2017-01-18 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20170118094212epcas5p22e588016d2b330dcd0b99b6e1012c744@epcas5p2.samsung.com>
>From MFCv6 onwards encoder stream buffer and decoder CPB buffer
need to be aligned with 512.
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 9 +++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 3 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index d6f207e..57da798 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -408,8 +408,15 @@ static int s5p_mfc_set_dec_stream_buffer_v6(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_dev *dev = ctx->dev;
const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
struct s5p_mfc_buf_size *buf_size = dev->variant->buf_size;
+ size_t cpb_buf_size;
mfc_debug_enter();
+ cpb_buf_size = ALIGN(buf_size->cpb, CPB_ALIGN);
+ if (strm_size >= set_strm_size_max(cpb_buf_size)) {
+ mfc_debug(2, "Decrease strm_size : %u -> %zu, gap : %d\n",
+ strm_size, set_strm_size_max(cpb_buf_size), CPB_ALIGN);
+ strm_size = set_strm_size_max(cpb_buf_size);
+ }
mfc_debug(2, "inst_no: %d, buf_addr: 0x%08x,\n"
"buf_size: 0x%08x (%d)\n",
ctx->inst_no, buf_addr, strm_size, strm_size);
@@ -519,6 +526,8 @@ static int s5p_mfc_set_enc_stream_buffer_v6(struct s5p_mfc_ctx *ctx,
struct s5p_mfc_dev *dev = ctx->dev;
const struct s5p_mfc_regs *mfc_regs = dev->mfc_regs;
+ size = ALIGN(size, 512);
+
writel(addr, mfc_regs->e_stream_buffer_addr); /* 16B align */
writel(size, mfc_regs->e_stream_buffer_size);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
index 8055848..16a7b1d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
@@ -40,6 +40,9 @@
#define FRAME_DELTA_H264_H263 1
#define TIGHT_CBR_MAX 10
+#define CPB_ALIGN 512
+#define set_strm_size_max(cpb_max) ((cpb_max) - CPB_ALIGN)
+
struct s5p_mfc_hw_ops *s5p_mfc_init_hw_ops_v6(void);
const struct s5p_mfc_regs *s5p_mfc_init_regs_v6_plus(struct s5p_mfc_dev *dev);
#endif /* S5P_MFC_OPR_V6_H_ */
--
1.7.2.3
^ permalink raw reply related
* [PATCH v2 12/14] ARM: dts: da850: add pinmux settings for the SATA controller
From: Sekhar Nori @ 2017-01-18 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484655976-25382-13-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
On Tuesday 17 January 2017 05:56 PM, Bartosz Golaszewski wrote:
> Add pinmux sub-nodes for all muxed SATA pins.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Since these are all unused at this time, we should drop adding them
until a time someone really needs these.
Thanks,
Sekhar
^ permalink raw reply
* [RESEND PATCH 0/2] Add i2c DT binding and device node for Mediatek MT2701 Soc
From: Jun Gao @ 2017-01-18 9:40 UTC (permalink / raw)
To: linux-arm-kernel
This patch series based on v4.10-rc2, include MT2701 i2c DT binding and device node.
Dependent on "Add clock and power domain DT nodes for Mediatek MT2701"[1].
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-December/007637.html
Jun Gao (2):
Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc
Platform
arm: dts: mt2701: Add i2c device node
.../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++---
arch/arm/boot/dts/mt2701-evb.dts | 44 ++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 42 +++++++++++++++++++
3 files changed, 92 insertions(+), 5 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RESEND PATCH 1/2] Documentation: devicetree: Add i2c binding for mediatek MT2701 Soc Platform
From: Jun Gao @ 2017-01-18 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484732461-13594-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
This add i2c DT binding to i2c-mt6577.txt for MT2701.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
.../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
index 0ce6fa3..ef22ecf 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
@@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: value should be either of the following.
- (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
- (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
- (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
- (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
- (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
+ "mediatek,mt2701-i2c", for i2c compatible with mt2701 i2c.
+ "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
+ "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
+ "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
+ "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
+ "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
- reg: physical base address of the controller and dma base, length of memory
mapped region.
- interrupts: interrupt number to the cpu.
--
1.7.9.5
^ permalink raw reply related
* [RESEND PATCH 2/2] arm: dts: mt2701: Add i2c device node
From: Jun Gao @ 2017-01-18 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484732461-13594-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add i2c device node for MT2701.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
arch/arm/boot/dts/mt2701-evb.dts | 44 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/mt2701.dtsi | 42 ++++++++++++++++++++++++++++++++++++
2 files changed, 86 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index 082ca88..a908e94 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -24,6 +24,50 @@
};
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins_a>;
+ status = "okay";
+};
+
+&pio {
+ i2c0_pins_a: i2c0 at 0 {
+ pins1 {
+ pinmux = <MT2701_PIN_75_SDA0__FUNC_SDA0>,
+ <MT2701_PIN_76_SCL0__FUNC_SCL0>;
+ bias-disable;
+ };
+ };
+
+ i2c1_pins_a: i2c1 at 0 {
+ pins1 {
+ pinmux = <MT2701_PIN_57_SDA1__FUNC_SDA1>,
+ <MT2701_PIN_58_SCL1__FUNC_SCL1>;
+ bias-disable;
+ };
+ };
+
+ i2c2_pins_a: i2c2 at 0 {
+ pins1 {
+ pinmux = <MT2701_PIN_77_SDA2__FUNC_SDA2>,
+ <MT2701_PIN_78_SCL2__FUNC_SCL2>;
+ bias-disable;
+ };
+ };
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index bdf8954..0d1539f 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -227,6 +227,48 @@
status = "disabled";
};
+ i2c0: i2c at 11007000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11007000 0 0x70>,
+ <0 0x11000200 0 0x80>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C0>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11008000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11008000 0 0x70>,
+ <0 0x11000280 0 0x80>;
+ interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C1>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at 11009000 {
+ compatible = "mediatek,mt2701-i2c",
+ "mediatek,mt6577-i2c";
+ reg = <0 0x11009000 0 0x70>,
+ <0 0x11000300 0 0x80>;
+ interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_LOW>;
+ clock-div = <16>;
+ clocks = <&pericfg CLK_PERI_I2C2>, <&pericfg CLK_PERI_AP_DMA>;
+ clock-names = "main", "dma";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
mmsys: syscon at 14000000 {
compatible = "mediatek,mt2701-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Benjamin Gaignard @ 2017-01-18 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170118092021.GE18989@ulmo.ba.sec>
2017-01-18 10:20 GMT+01:00 Thierry Reding <thierry.reding@gmail.com>:
> On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
>> Define bindings for pwm-stm32
>>
>> version 6:
>> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>>
>> version 2:
>> - use parameters instead of compatible of handle the hardware configuration
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> new file mode 100644
>> index 0000000..866f222
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>> @@ -0,0 +1,33 @@
>> +STMicroelectronics STM32 Timers PWM bindings
>> +
>> +Must be a sub-node of an STM32 Timers device tree node.
>> +See ../mfd/stm32-timers.txt for details about the parent node.
>> +
>> +Required parameters:
>> +- compatible: Must be "st,stm32-pwm".
>> +- pinctrl-names: Set to "default".
>> +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
>> + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
>> +
>> +Optional parameters:
>> +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
>> + "index" indicates on which break input the configuration should be applied.
>
> It might be useful to specify what the valid values are for the break
> input index.
It could 0 and 1, I will add this information.
>
> Also, u32 is kind of a Linuxism, perhaps "Arrays of three cells"? Also,
> does this mean there can be multiple entries? Such as 6 cells for two
> configurations? What's the maximum number of such configurations?
>
> If it's possible to specify multiple configurations, maybe a slightly
> clearer wording would be: "One or more <index level filter> triplets to
> describe..."
>
You can have one configuration per index so I will rephrase it like that:
One or two <index level filter> to describe break input configurations.
"index" indicates on which break input (0 or 1 ) the configuration
should be applied.
>> + "level" gives the active level (0=low or 1=high) for this configuration.
>
> So how does this work exactly? "level" specifies the output level if the
> filter value is matched?
No it specify on which input level the break event is generated
>
>> + "filter" gives the filtering value to be applied.
>
> Is this a single value at which "level" will be applied? Or is it an
> upper/lower bound that can be used to restrict the output to "level" if
> the signal goes beyond/below a certain threshold?
Very very basically filter is more a debounce value set on the signal
to avoid glitches.
The goal of break input feature is to stop PWM generation in hardware
errors failure case.
For a more completed description you can read "using break input
function" (starting page 645) in this doc:
http://www.st.com/content/ccc/resource/technical/document/reference_manual/c5/cf/ef/52/c0/f1/4b/fa/DM00124865.pdf/files/DM00124865.pdf/jcr:content/translations/en.DM00124865.pdf
>
> Maybe an example would clarify this. Or perhaps a reference to a manual
> where a more in-depth description of this functionality can be found.
>
> Thierry
--
Benjamin Gaignard
Graphic Study Group
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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