* [PATCH 2/2] ARM: dts: r8a7792: move timer node out of bus
From: Geert Uytterhoeven @ 2017-12-19 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218213233.3373-3-horms+renesas@verge.net.au>
On Mon, Dec 18, 2017 at 10:32 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> The timer node does not have any register properties and thus shouldn't be
> placed on the bus.
>
> This problem is flagged by the compiler as follows:
> $ make dtbs W=1
> ...
> DTC arch/arm/boot/dts/r8a7792-wheat.dtb
> arch/arm/boot/dts/r8a7792-blanche.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
> arch/arm/boot/dts/r8a7792-wheat.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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 1/2] ARM: dts: r8a7792: sort root sub-nodes alphabetically
From: Geert Uytterhoeven @ 2017-12-19 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218213233.3373-2-horms+renesas@verge.net.au>
On Mon, Dec 18, 2017 at 10:32 PM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
to allow for
> of this file.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
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] i2c: stm32: Fixes multibyte transfer for STM32F4 I2C controller
From: Radosław Pietrzyk @ 2017-12-19 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dae4399e-4209-b052-a4c0-8a11c17ce032@st.com>
My understanding is that this driver is currently vulnerable to any
IRQ delays that may happen in the system and this patch eliminates the
problem but you may prove me wrong.
2017-12-07 14:23 GMT+01:00 Pierre Yves MORDRET <pierre-yves.mordret@st.com>:
>
> I do believe some investigation has to be done prior merging this patch.
> The impact is genuine and has to be tested thoroughly before granting an ack.
>
> Thus I prefer having a better understanding of the issue.
> I will try to work on this later on.
>
> Regards
>
>
> On 12/07/2017 11:52 AM, Wolfram Sang wrote:
>> On Tue, Oct 24, 2017 at 01:45:43PM +0200, Rados?aw Pietrzyk wrote:
>>> I'm afraid that didn't help and the problem still exists even with
>>> those patches applied.
>>
>> So, my reading is: There is an issue which needs to be investigated?
>> Does applying the patch make sense until the issue is fully understood?
>>
^ permalink raw reply
* [PATCH 1/2] clocksource: timer-dm: Make unexported functions static
From: Keerthy @ 2017-12-19 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218113056.GA18637@lenoch>
On Monday 18 December 2017 05:00 PM, Ladislav Michl wrote:
> As dmtimer no longer exports functions, there is no point
> to have them non-static. Also delete those not used anywhere.
I will refrain from this patch at the moment. I have plans of another
series to do some more cleanups. For now want to keep the changes minimal.
Some of the functions that you are removing in this patch might be
needed and can be added for ops in future.
So i will let this be separate patch.
Thanks,
Keerthy
>
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
> drivers/clocksource/timer-dm.c | 125 ++++++++---------------------------------
> include/clocksource/dmtimer.h | 26 ---------
> 2 files changed, 23 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> index 392978ccd8a6..ec3a28c90c70 100644
> --- a/drivers/clocksource/timer-dm.c
> +++ b/drivers/clocksource/timer-dm.c
> @@ -204,16 +204,6 @@ static inline u32 omap_dm_timer_reserved_systimer(int id)
> return (omap_reserved_systimers & (1 << (id - 1))) ? 1 : 0;
> }
>
> -int omap_dm_timer_reserve_systimer(int id)
> -{
> - if (omap_dm_timer_reserved_systimer(id))
> - return -ENODEV;
> -
> - omap_reserved_systimers |= (1 << (id - 1));
> -
> - return 0;
> -}
> -
> static struct omap_dm_timer *_omap_dm_timer_request(int req_type, void *data)
> {
> struct omap_dm_timer *timer = NULL, *t;
> @@ -298,16 +288,16 @@ static struct omap_dm_timer *_omap_dm_timer_request(int req_type, void *data)
> return timer;
> }
>
> -struct omap_dm_timer *omap_dm_timer_request(void)
> +static struct omap_dm_timer *omap_dm_timer_request(void)
> {
> return _omap_dm_timer_request(REQUEST_ANY, NULL);
> }
>
> -struct omap_dm_timer *omap_dm_timer_request_specific(int id)
> +static struct omap_dm_timer *omap_dm_timer_request_specific(int id)
> {
> /* Requesting timer by ID is not supported when device tree is used */
> if (of_have_populated_dt()) {
> - pr_warn("%s: Please use omap_dm_timer_request_by_cap/node()\n",
> + pr_warn("%s: Please use omap_dm_timer_request_by_node()\n",
> __func__);
> return NULL;
> }
> @@ -315,20 +305,6 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
> return _omap_dm_timer_request(REQUEST_BY_ID, &id);
> }
>
> -/**
> - * omap_dm_timer_request_by_cap - Request a timer by capability
> - * @cap: Bit mask of capabilities to match
> - *
> - * Find a timer based upon capabilities bit mask. Callers of this function
> - * should use the definitions found in the plat/dmtimer.h file under the
> - * comment "timer capabilities used in hwmod database". Returns pointer to
> - * timer handle on success and a NULL pointer on failure.
> - */
> -struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
> -{
> - return _omap_dm_timer_request(REQUEST_BY_CAP, &cap);
> -}
> -
> /**
> * omap_dm_timer_request_by_node - Request a timer by device-tree node
> * @np: Pointer to device-tree timer node
> @@ -336,7 +312,7 @@ struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap)
> * Request a timer based upon a device node pointer. Returns pointer to
> * timer handle on success and a NULL pointer on failure.
> */
> -struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np)
> +static struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np)
> {
> if (!np)
> return NULL;
> @@ -344,7 +320,7 @@ struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np)
> return _omap_dm_timer_request(REQUEST_BY_NODE, np);
> }
>
> -int omap_dm_timer_free(struct omap_dm_timer *timer)
> +static int omap_dm_timer_free(struct omap_dm_timer *timer)
> {
> if (unlikely(!timer))
> return -EINVAL;
> @@ -424,7 +400,7 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>
> #else
>
> -struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> +static struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> {
> if (timer && !IS_ERR(timer->fclk))
> return timer->fclk;
> @@ -440,18 +416,7 @@ __u32 omap_dm_timer_modify_idlect_mask(__u32 inputmask)
>
> #endif
>
> -int omap_dm_timer_trigger(struct omap_dm_timer *timer)
> -{
> - if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev))) {
> - pr_err("%s: timer not available or enabled.\n", __func__);
> - return -EINVAL;
> - }
> -
> - omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0);
> - return 0;
> -}
> -
> -int omap_dm_timer_start(struct omap_dm_timer *timer)
> +static int omap_dm_timer_start(struct omap_dm_timer *timer)
> {
> u32 l;
>
> @@ -471,7 +436,7 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
> return 0;
> }
>
> -int omap_dm_timer_stop(struct omap_dm_timer *timer)
> +static int omap_dm_timer_stop(struct omap_dm_timer *timer)
> {
> unsigned long rate = 0;
>
> @@ -556,8 +521,8 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
> return ret;
> }
>
> -int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
> - unsigned int load)
> +static int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
> + unsigned int load)
> {
> u32 l;
>
> @@ -581,37 +546,8 @@ int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload,
> return 0;
> }
>
> -/* Optimized set_load which removes costly spin wait in timer_start */
> -int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload,
> - unsigned int load)
> -{
> - u32 l;
> -
> - if (unlikely(!timer))
> - return -EINVAL;
> -
> - omap_dm_timer_enable(timer);
> -
> - l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
> - if (autoreload) {
> - l |= OMAP_TIMER_CTRL_AR;
> - omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
> - } else {
> - l &= ~OMAP_TIMER_CTRL_AR;
> - }
> - l |= OMAP_TIMER_CTRL_ST;
> -
> - __omap_dm_timer_load_start(timer, l, load, timer->posted);
> -
> - /* Save the context */
> - timer->context.tclr = l;
> - timer->context.tldr = load;
> - timer->context.tcrr = load;
> - return 0;
> -}
> -
> -int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
> - unsigned int match)
> +static int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
> + unsigned int match)
> {
> u32 l;
>
> @@ -634,8 +570,8 @@ int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable,
> return 0;
> }
>
> -int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
> - int toggle, int trigger)
> +static int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
> + int toggle, int trigger)
> {
> u32 l;
>
> @@ -659,7 +595,8 @@ int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on,
> return 0;
> }
>
> -int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler)
> +static int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer,
> + int prescaler)
> {
> u32 l;
>
> @@ -681,8 +618,8 @@ int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler)
> return 0;
> }
>
> -int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer,
> - unsigned int value)
> +static int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer,
> + unsigned int value)
> {
> if (unlikely(!timer))
> return -EINVAL;
> @@ -704,7 +641,7 @@ int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer,
> *
> * Disables the specified timer interrupts for a timer.
> */
> -int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
> +static int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
> {
> u32 l = mask;
>
> @@ -727,7 +664,7 @@ int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask)
> return 0;
> }
>
> -unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
> +static unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
> {
> unsigned int l;
>
> @@ -741,7 +678,7 @@ unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer)
> return l;
> }
>
> -int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value)
> +static int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value)
> {
> if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev)))
> return -EINVAL;
> @@ -751,7 +688,7 @@ int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value)
> return 0;
> }
>
> -unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer)
> +static unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer)
> {
> if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev))) {
> pr_err("%s: timer not iavailable or enabled.\n", __func__);
> @@ -761,7 +698,7 @@ unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer)
> return __omap_dm_timer_read_counter(timer, timer->posted);
> }
>
> -int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value)
> +static int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value)
> {
> if (unlikely(!timer || pm_runtime_suspended(&timer->pdev->dev))) {
> pr_err("%s: timer not available or enabled.\n", __func__);
> @@ -775,22 +712,6 @@ int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value)
> return 0;
> }
>
> -int omap_dm_timers_active(void)
> -{
> - struct omap_dm_timer *timer;
> -
> - list_for_each_entry(timer, &omap_timer_list, node) {
> - if (!timer->reserved)
> - continue;
> -
> - if (omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG) &
> - OMAP_TIMER_CTRL_ST) {
> - return 1;
> - }
> - }
> - return 0;
> -}
> -
> static const struct of_device_id omap_timer_match[];
>
> /**
> diff --git a/include/clocksource/dmtimer.h b/include/clocksource/dmtimer.h
> index 862ad62dab9d..63d6ec0747d9 100644
> --- a/include/clocksource/dmtimer.h
> +++ b/include/clocksource/dmtimer.h
> @@ -124,40 +124,14 @@ struct omap_dm_timer {
> struct list_head node;
> };
>
> -int omap_dm_timer_reserve_systimer(int id);
> -struct omap_dm_timer *omap_dm_timer_request(void);
> -struct omap_dm_timer *omap_dm_timer_request_specific(int timer_id);
> -struct omap_dm_timer *omap_dm_timer_request_by_cap(u32 cap);
> -struct omap_dm_timer *omap_dm_timer_request_by_node(struct device_node *np);
> -int omap_dm_timer_free(struct omap_dm_timer *timer);
> void omap_dm_timer_enable(struct omap_dm_timer *timer);
> void omap_dm_timer_disable(struct omap_dm_timer *timer);
>
> int omap_dm_timer_get_irq(struct omap_dm_timer *timer);
>
> u32 omap_dm_timer_modify_idlect_mask(u32 inputmask);
> -struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer);
> -
> -int omap_dm_timer_trigger(struct omap_dm_timer *timer);
> -int omap_dm_timer_start(struct omap_dm_timer *timer);
> -int omap_dm_timer_stop(struct omap_dm_timer *timer);
>
> int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source);
> -int omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload, unsigned int value);
> -int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload, unsigned int value);
> -int omap_dm_timer_set_match(struct omap_dm_timer *timer, int enable, unsigned int match);
> -int omap_dm_timer_set_pwm(struct omap_dm_timer *timer, int def_on, int toggle, int trigger);
> -int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer, int prescaler);
> -
> -int omap_dm_timer_set_int_enable(struct omap_dm_timer *timer, unsigned int value);
> -int omap_dm_timer_set_int_disable(struct omap_dm_timer *timer, u32 mask);
> -
> -unsigned int omap_dm_timer_read_status(struct omap_dm_timer *timer);
> -int omap_dm_timer_write_status(struct omap_dm_timer *timer, unsigned int value);
> -unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer);
> -int omap_dm_timer_write_counter(struct omap_dm_timer *timer, unsigned int value);
> -
> -int omap_dm_timers_active(void);
>
> /*
> * Do not use the defines below, they are not needed. They should be only
>
^ permalink raw reply
* [PATCH] clk: sunxi: sun9i-mmc: Implement reset callback for reset controls
From: Maxime Ripard @ 2017-12-19 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218210709.GY7997@codeaurora.org>
On Mon, Dec 18, 2017 at 01:07:09PM -0800, Stephen Boyd wrote:
> On 12/18, Chen-Yu Tsai wrote:
> > Our MMC host driver now issues a reset, instead of just deasserting
> > the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the
> > device at probe time"). The sun9i-mmc clock driver does not support
> > this, and will fail, which results in MMC not probing.
> >
> > This patch implements the reset callback by asserting the reset control,
> > then deasserting it after a small delay.
> >
> > Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets")
> > Cc: <stable@vger.kernel.org> # 4.14.x
> > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > ---
>
> Did you want us to pick this up into clk-fixes? It seems to be
> causing MMC to not work for some time? That sounds annoying
> enough.
That would be great, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171219/86f9bd6a/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] clocksource: timer-dm: Check prescaler value
From: Keerthy @ 2017-12-19 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218113153.GB18637@lenoch>
On Monday 18 December 2017 05:01 PM, Ladislav Michl wrote:
> Invalid prescaler value is silently ignored. Fix that
> by returning -EINVAL in such case. As invalid value
> disabled use of the prescaler, use -1 explicitely for
> that purpose.
Thanks. I will post this as part of my migration series.
>
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
> drivers/clocksource/timer-dm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
> index ec3a28c90c70..95cd98be8541 100644
> --- a/drivers/clocksource/timer-dm.c
> +++ b/drivers/clocksource/timer-dm.c
> @@ -609,6 +609,9 @@ static int omap_dm_timer_set_prescaler(struct omap_dm_timer *timer,
> if (prescaler >= 0x00 && prescaler <= 0x07) {
> l |= OMAP_TIMER_CTRL_PRE;
> l |= prescaler << 2;
> + } else {
> + if (prescaler != -1)
> + return -EINVAL;
> }
> omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
>
>
^ permalink raw reply
* [PATCH 3/8] media: v4l2-async: simplify v4l2_async_subdev structure
From: Sakari Ailus @ 2017-12-19 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <014b64d13c8b9d516afc3319a9de1a97b2a845de.1513625884.git.mchehab@s-opensource.com>
On Mon, Dec 18, 2017 at 05:53:57PM -0200, Mauro Carvalho Chehab wrote:
> The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> match criteria requires just a device name.
>
> So, it doesn't make sense to enclose those into structs,
> as the criteria can go directly into the union.
>
> That makes easier to document it, as we don't need to document
> weird senseless structs.
>
> At drivers, this makes even clearer about the match criteria.
>
> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
I'm not sure this is needed but it doesn't break anything either.
Feel free to add:
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Sakari Ailus
e-mail: sakari.ailus at iki.fi
^ permalink raw reply
* [PATCH v5 7/8] pwm: pwm-omap-dmtimer: Adapt driver to utilize dmtimer pdata ops
From: Keerthy @ 2017-12-19 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b780d238-91fa-035e-65dc-4e8ee607f6a7@ti.com>
On Tuesday 19 December 2017 10:28 AM, Keerthy wrote:
>
>
> On Monday 18 December 2017 06:25 PM, Keerthy wrote:
>>
>>
>> On Monday 18 December 2017 03:01 PM, Ladislav Michl wrote:
>>> Keerthy,
>>>
>>> On Tue, Dec 12, 2017 at 11:42:16AM +0530, Keerthy wrote:
>>>> Adapt driver to utilize dmtimer pdata ops instead of pdata-quirks.
>>>>
>>>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>>>> ---
>>>>
>>>> Changes in v4:
>>>>
>>>> * Switched to dev_get_platdata.
>>>
>>> Where do you expect dev.platform_data to be set? PWM driver is failing
>>> with:
>>> omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL
>>> omap-dmtimer-pwm: probe of dmtimer-pwm failed with error -22
>>>
>>> Which I fixed with patch bellow, to be able to test your patchset.
>>
>> Thanks! I will make the below patch part of my series.
>>
>>>
>>> Also I'm running a bit out of time, so I'll send few clean up
>>> patches and event capture code to get some feedback early.
>>>
>>> Regards,
>>> ladis
>>>
>>> diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
>>> index 39be39e6a8dd..d3d8a49cae0d 100644
>>> --- a/drivers/clocksource/timer-dm.c
>>> +++ b/drivers/clocksource/timer-dm.c
>>> @@ -773,6 +773,7 @@ static int omap_dm_timer_probe(struct platform_device *pdev)
>>> dev_err(dev, "%s: no platform data.\n", __func__);
>>> return -ENODEV;
>>> }
>>> + dev->platform_data = pdata;
>
> drivers/clocksource/timer-dm.c: In function 'omap_dm_timer_probe':
> drivers/clocksource/timer-dm.c:744:21: warning: assignment discards
> 'const' qualifier from pointer target type
>
> This cannot be done as we are assigning a const pointer to a non-const
> pointer.
>
> I will figure out a different way for this fix.
Ladis,
I fixed that:
diff --git a/drivers/clocksource/timer-dm.c b/drivers/clocksource/timer-dm.c
index 1cbd954..e58f555 100644
--- a/drivers/clocksource/timer-dm.c
+++ b/drivers/clocksource/timer-dm.c
@@ -807,17 +807,21 @@ static int omap_dm_timer_probe(struct
platform_device *pdev)
struct resource *mem, *irq;
struct device *dev = &pdev->dev;
const struct of_device_id *match;
- const struct dmtimer_platform_data *pdata;
+ struct dmtimer_platform_data *pdata;
int ret;
match = of_match_device(of_match_ptr(omap_timer_match), dev);
- pdata = match ? match->data : dev->platform_data;
+ pdata = match ? (struct dmtimer_platform_data *)match->data :
+ dev->platform_data;
if (!pdata && !dev->of_node) {
dev_err(dev, "%s: no platform data.\n", __func__);
return -ENODEV;
}
+ if (!dev->platform_data)
+ dev->platform_data = pdata;
+
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (unlikely(!irq)) {
dev_err(dev, "%s: no IRQ resource.\n", __func__);
@@ -946,7 +950,7 @@ static int omap_dm_timer_remove(struct
platform_device *pdev)
.write_status = omap_dm_timer_write_status,
};
-static const struct dmtimer_platform_data omap3plus_pdata = {
+static struct dmtimer_platform_data omap3plus_pdata = {
.timer_errata = OMAP_TIMER_ERRATA_I103_I767,
.timer_ops = &dmtimer_ops,
};
Can you check at your end if this works for you?
>
>>>
>>> irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>>> if (unlikely(!irq)) {
>>>
>>>>
>>>> Changes in v3:
>>>>
>>>> * Used of_find_platdata_by_node function to fetch platform
>>>> data for timer node.
>>>>
>>>> drivers/pwm/pwm-omap-dmtimer.c | 39 ++++++++++++++++++++++-----------------
>>>> 1 file changed, 22 insertions(+), 17 deletions(-)
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply related
* [PATCH] fix perl locale warnings in arch/arm/boot/
From: Masahiro Yamada @ 2017-12-19 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215201639.GA32042@amd>
2017-12-16 5:16 GMT+09:00 Pavel Machek <pavel@ucw.cz>:
> On Mon 2017-11-27 10:46:20, Pavel Machek wrote:
>>
>> Commit 429f7a062e3b5cf6fcf01eb00600cee5fe4d751f introduced perl into
>> arch/arm/boot/compressed/Makefile, which unfortunately leads to locale
>> warnings.
>>
>> Fix it by setting default locale.
>>
>> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> RMK apparently can't be bothered to fix the stuff he broke. Can
> someone take the patch? Arm-soc? Linus? Andrew?
>
> Thanks,
> Pavel
Russell does not directly pick up patches from ML.
If you want him to apply your patch,
you need to put it in his patch tracker.
(patches at arm.linux.org.uk)
>> diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile
>> index 45a6b9b..4656e98 100644
>> --- a/arch/arm/boot/compressed/Makefile
>> +++ b/arch/arm/boot/compressed/Makefile
>> @@ -118,7 +118,7 @@ asflags-y := -DZIMAGE
>>
>> # Supply kernel BSS size to the decompressor via a linker symbol.
>> KBSS_SZ = $(shell $(CROSS_COMPILE)nm $(obj)/../../../../vmlinux | \
>> - perl -e 'while (<>) { \
>> + LC_ALL=C perl -e 'while (<>) { \
>> $$bss_start=hex($$1) if /^([[:xdigit:]]+) B __bss_start$$/; \
>> $$bss_end=hex($$1) if /^([[:xdigit:]]+) B __bss_stop$$/; \
>> }; printf "%d\n", $$bss_end - $$bss_start;')
>>
>>
>
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Miquel RAYNAL @ 2017-12-19 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219081941.utke7dh5bmmlub6h@sapphire.tkos.co.il>
Hi Baruch,
On Tue, 19 Dec 2017 10:19:41 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Tue, Dec 19, 2017 at 09:08:14AM +0100, Miquel RAYNAL wrote:
> > On Tue, 19 Dec 2017 07:51:54 +0200
> > Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> > > > On Mon, 18 Dec 2017 22:35:42 +0200
> > > > Baruch Siach <baruch@tkos.co.il> wrote:
> > > > > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal
> > > > > wrote:
> > > > > > Bindings were incomplete for a long time by only exposing
> > > > > > one of the two available control registers. To ease the
> > > > > > migration to the full bindings (already in use for the
> > > > > > Armada 375 SoC), rename the pointers for clarification.
> > > > > > This way, it will only be needed to add another pointer to
> > > > > > access the other control register when the time comes.
> > > > > >
> > > > > > This avoids dangerous situations where the offset 0 of the
> > > > > > control area can be either one register or the other
> > > > > > depending on the bindings used. After this change, device
> > > > > > trees of other SoCs could be migrated to the "full"
> > > > > > bindings if they may benefit from features from the
> > > > > > unaccessible register, without any change in the driver.
> > > > > >
> > > > > > Signed-off-by: Miquel Raynal
> > > > > > <miquel.raynal@free-electrons.com> Reviewed-by: Gregory
> > > > > > CLEMENT <gregory.clement@free-electrons.com> ---
> > > > >
> > > > > [...]
> > > > >
> > > > > > + /*
> > > > > > + * Legacy DT bindings only described "control1"
> > > > > > register (also referred
> > > > > > + * as "control MSB" on old documentation). New
> > > > > > bindings cover
> > > > > > + * "control0/control LSB" and "control1/control
> > > > > > MSB" registers within
> > > > > > + * the same resource, which is then of size 8
> > > > > > instead of 4.
> > > > > > + */
> > > > > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > > > > + /* ->control0 unavailable in this
> > > > > > configuration */
> > > > > > + priv->control1 = control +
> > > > > > LEGACY_CONTROL1_OFFSET;
> > > > > > + } else {
> > > > > > + priv->control0 = control + CONTROL0_OFFSET;
> > > > > > + priv->control1 = control + CONTROL1_OFFSET;
> > > > > > + }
> > > > >
> > > > > The needs_control0 field that you mentioned in the cover page
> > > > > is missing here.
> > > >
> > > > Yes, at this point nobody actually *needs* control0 so the
> > > > limitation is added with the patch that introduce ap806 support
> > > > as it is the first compatible that needs both control0 and
> > > > control1 to work correctly. Does this bother you?
> > >
> > > No. It is just that we agreed to have a verification here that the
> > > size of the control registers resource matches the binding. I
> > > thought that the needs_control0 field that you mention in the
> > > cover page is meant to implement that.
> >
> > That is absolutely right, but at this point in the series, the
> > supported compatible strings are
> > "marvell,armada[370|375|38x|xp]-thermal". All of them can use both
> > bindings so I don't see the point to have a needs_control0 field in
> > this patch. It is introduced in the next patch that adds support
> > for ap806 by only supporting the new bindings though.
>
> OK. Makes sense.
>
> > > necessary. It would just make sure that no one introduces a DT
> > > with the wrong resource size.
> >
> > Not sure I understand what exactly you wanna check, can you
> > give me an example?
>
> I wrote that before it occurred to me that we can use the control
> registers size the distinguish between the old binding and the new
> one.
>
> I still think it would be nice to add needs_control0=true to
> armada375_data, for consistency with the ap806 and cp110.
Oh that is right, I forgot about that. I will add it and move the
need_control0 boolean to this patch.
Thank you,
Miqu?l
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Baruch Siach @ 2017-12-19 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219090814.3a53ec3d@xps13>
Hi Miqu?l,
On Tue, Dec 19, 2017 at 09:08:14AM +0100, Miquel RAYNAL wrote:
> On Tue, 19 Dec 2017 07:51:54 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> > On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> > > On Mon, 18 Dec 2017 22:35:42 +0200
> > > Baruch Siach <baruch@tkos.co.il> wrote:
> > > > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> > > > > Bindings were incomplete for a long time by only exposing one of
> > > > > the two available control registers. To ease the migration to
> > > > > the full bindings (already in use for the Armada 375 SoC),
> > > > > rename the pointers for clarification. This way, it will only
> > > > > be needed to add another pointer to access the other control
> > > > > register when the time comes.
> > > > >
> > > > > This avoids dangerous situations where the offset 0 of the
> > > > > control area can be either one register or the other depending
> > > > > on the bindings used. After this change, device trees of other
> > > > > SoCs could be migrated to the "full" bindings if they may
> > > > > benefit from features from the unaccessible register, without
> > > > > any change in the driver.
> > > > >
> > > > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > > > Reviewed-by: Gregory CLEMENT
> > > > > <gregory.clement@free-electrons.com> ---
> > > >
> > > > [...]
> > > >
> > > > > + /*
> > > > > + * Legacy DT bindings only described "control1"
> > > > > register (also referred
> > > > > + * as "control MSB" on old documentation). New bindings
> > > > > cover
> > > > > + * "control0/control LSB" and "control1/control MSB"
> > > > > registers within
> > > > > + * the same resource, which is then of size 8 instead
> > > > > of 4.
> > > > > + */
> > > > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > > > + /* ->control0 unavailable in this
> > > > > configuration */
> > > > > + priv->control1 = control +
> > > > > LEGACY_CONTROL1_OFFSET;
> > > > > + } else {
> > > > > + priv->control0 = control + CONTROL0_OFFSET;
> > > > > + priv->control1 = control + CONTROL1_OFFSET;
> > > > > + }
> > > >
> > > > The needs_control0 field that you mentioned in the cover page is
> > > > missing here.
> > >
> > > Yes, at this point nobody actually *needs* control0 so the
> > > limitation is added with the patch that introduce ap806 support as
> > > it is the first compatible that needs both control0 and control1 to
> > > work correctly. Does this bother you?
> >
> > No. It is just that we agreed to have a verification here that the
> > size of the control registers resource matches the binding. I thought
> > that the needs_control0 field that you mention in the cover page is
> > meant to implement that.
>
> That is absolutely right, but at this point in the series, the supported
> compatible strings are "marvell,armada[370|375|38x|xp]-thermal". All of
> them can use both bindings so I don't see the point to have a
> needs_control0 field in this patch. It is introduced in the next patch
> that adds support for ap806 by only supporting the new bindings
> though.
OK. Makes sense.
> > necessary. It would just make sure that no one introduces a DT with
> > the wrong resource size.
>
> Not sure I understand what exactly you wanna check, can you
> give me an example?
I wrote that before it occurred to me that we can use the control registers
size the distinguish between the old binding and the new one.
I still think it would be nice to add needs_control0=true to armada375_data,
for consistency with the ap806 and cp110.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 23/25] arm: da8: dts: Remove leading 0x and 0s from bindings notation
From: Sekhar Nori @ 2017-12-19 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215124657.31052-1-malat@debian.org>
On Friday 15 December 2017 06:16 PM, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
Applied to v4.16/fixes-non-critical with some headline adjustments.
The subject prefix we use for this file is "ARM: dts: da850-lcdk:". You
can check that with 'git log --oneline'
Also, you are not fixing bindings notation here, but the actual device
tree source itself. So:
"
ARM: dts: da850-lcdk: Remove leading 0x and 0s from unit address
"
Thanks for the patch!
Sekhar
^ permalink raw reply
* [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Miquel RAYNAL @ 2017-12-19 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219055154.f23leaob3zndmmqo@sapphire.tkos.co.il>
On Tue, 19 Dec 2017 07:51:54 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Tue, Dec 19, 2017 at 01:32:33AM +0100, Miquel RAYNAL wrote:
> > On Mon, 18 Dec 2017 22:35:42 +0200
> > Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Mon, Dec 18, 2017 at 03:36:35PM +0100, Miquel Raynal wrote:
> > > > Bindings were incomplete for a long time by only exposing one of
> > > > the two available control registers. To ease the migration to
> > > > the full bindings (already in use for the Armada 375 SoC),
> > > > rename the pointers for clarification. This way, it will only
> > > > be needed to add another pointer to access the other control
> > > > register when the time comes.
> > > >
> > > > This avoids dangerous situations where the offset 0 of the
> > > > control area can be either one register or the other depending
> > > > on the bindings used. After this change, device trees of other
> > > > SoCs could be migrated to the "full" bindings if they may
> > > > benefit from features from the unaccessible register, without
> > > > any change in the driver.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > > Reviewed-by: Gregory CLEMENT
> > > > <gregory.clement@free-electrons.com> ---
> > >
> > > [...]
> > >
> > > > + /*
> > > > + * Legacy DT bindings only described "control1"
> > > > register (also referred
> > > > + * as "control MSB" on old documentation). New bindings
> > > > cover
> > > > + * "control0/control LSB" and "control1/control MSB"
> > > > registers within
> > > > + * the same resource, which is then of size 8 instead
> > > > of 4.
> > > > + */
> > > > + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > > > + /* ->control0 unavailable in this
> > > > configuration */
> > > > + priv->control1 = control +
> > > > LEGACY_CONTROL1_OFFSET;
> > > > + } else {
> > > > + priv->control0 = control + CONTROL0_OFFSET;
> > > > + priv->control1 = control + CONTROL1_OFFSET;
> > > > + }
> > >
> > > The needs_control0 field that you mentioned in the cover page is
> > > missing here.
> >
> > Yes, at this point nobody actually *needs* control0 so the
> > limitation is added with the patch that introduce ap806 support as
> > it is the first compatible that needs both control0 and control1 to
> > work correctly. Does this bother you?
>
> No. It is just that we agreed to have a verification here that the
> size of the control registers resource matches the binding. I thought
> that the needs_control0 field that you mention in the cover page is
> meant to implement that.
That is absolutely right, but at this point in the series, the supported
compatible strings are "marvell,armada[370|375|38x|xp]-thermal". All of
them can use both bindings so I don't see the point to have a
needs_control0 field in this patch. It is introduced in the next patch
that adds support for ap806 by only supporting the new bindings
though.
> necessary. It would just make sure that no one introduces a DT with
> the wrong resource size.
Not sure I understand what exactly you wanna check, can you
give me an example?
Thank you,
Miqu?l
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 6/6] arm: dts: sun8i: h3-h8: ir register size should be the whole memory block
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
The size of the register should be the size of the whole memory block,
not just the registers, that are needed.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 8d40c00d64bb..a9caeda4a574 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -674,7 +674,7 @@
clock-names = "apb", "ir";
resets = <&r_ccu RST_APB0_IR>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x01f02000 0x40>;
+ reg = <0x01f02000 0x400>;
status = "disabled";
};
--
2.11.0
^ permalink raw reply related
* [PATCH v3 5/6] arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Unlike the other IR receivers this one needs a base clock frequency
of 3000000 Hz (3 MHz), to be able to work.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..ffc6445fd281 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -82,6 +82,13 @@
};
};
+&cir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cir_pins>;
+ clock-frequency = <3000000>;
+ status = "okay";
+};
+
&ehci0 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
--
2.11.0
^ permalink raw reply related
* [PATCH v3 4/6] arm: dts: sun8i: a83t: Add support for the cir interface
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
The cir interface is like on the H3 located at 0x01f02000 and is exactly
the same. This patch adds support for the ir interface on the A83T.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 06e96db7c41a..ddc0d592107f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -605,6 +605,16 @@
#reset-cells = <1>;
};
+ cir: cir at 01f02000 {
+ compatible = "allwinner,sun5i-a13-ir";
+ clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_APB0_IR>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01f02000 0x400>;
+ status = "disabled";
+ };
+
r_pio: pinctrl at 1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/6] arm: dts: sun8i: a83t: Add the cir pin for the A83T
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
The CIR Pin of the A83T is located at PL12.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index de5119a2a91c..06e96db7c41a 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -617,6 +617,11 @@
interrupt-controller;
#interrupt-cells = <3>;
+ cir_pins: cir-pins at 0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
+
r_rsb_pins: r-rsb-pins {
pins = "PL0", "PL1";
function = "s_rsb";
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/6] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new optional property for the base clock
frequency.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..278098987edb 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -11,6 +11,8 @@ Required properties:
Optional properties:
- linux,rc-map-name: see rc.txt file in the same directory.
- resets : phandle + reset specifier pair
+- clock-frequency : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz
+ if missing.
Example:
@@ -18,6 +20,7 @@ ir0: ir at 1c21800 {
compatible = "allwinner,sun4i-a10-ir";
clocks = <&apb0_gates 6>, <&ir0_clk>;
clock-names = "apb", "ir";
+ clock-frequency = <3000000>;
resets = <&apb0_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-1-embed3d@gmail.com>
This patch updates the sunxi-ir driver to set the base clock frequency from
devicetree.
This is necessary since there are different ir receivers on the
market, that operate with different frequencies. So this value could be
set if the attached ir receiver needs a different base clock frequency,
than the default 8 MHz.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..f500cea228a9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,8 @@
/* CIR_REG register idle threshold */
#define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
-/* Required frequency for IR0 or IR1 clock in CIR mode */
+/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
#define SUNXI_IR_BASE_CLK 8000000
-/* Frequency after IR internal divider */
-#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
/* Idle Threshold in samples */
@@ -122,7 +118,8 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
- rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+ rawir.duration = ((dt & 0x7f) + 1) *
+ ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, &rawir);
}
}
@@ -148,6 +145,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+ u32 b_clk_freq = SUNXI_IR_BASE_CLK;
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +170,9 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
+ /* Base clock frequency (optional) */
+ of_property_read_u32(dn, "clock-frequency", &b_clk_freq);
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,11 +181,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+ ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
}
+ dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
if (clk_prepare_enable(ir->apb_clk)) {
dev_err(dev, "try to enable apb_ir_clk failed\n");
@@ -225,7 +227,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
- ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+ /* Frequency after IR internal divider with sample period in ns */
+ ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 0/6] arm: sunxi: IR support for A83T
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the sunxi A83T ir module and enhances
the sunxi-ir driver. Right now the base clock frequency for the ir driver
is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3
the ir receiver needs, a 3 MHz base clock frequency to work without
problems with this driver.
This patch series adds support for an optinal property that makes it able
to override the default base clock frequency and enables the ir interface
on the a83t and the Bananapi M3.
changes since v2:
* reorder cir pin (alphabetical)
* fix typo in documentation
changes since v1:
* fix typos, reword Documentation
* initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
* change dev_info() to dev_dbg()
* change naming to cir* in dts/dtsi
* Added acked Ackedi-by to related patch
* use whole memory block instead of registers needed + fix for h3/h5
changes since rfc:
* The property is now optinal. If the property is not available in
the dtb the driver uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency
Regards,
Philipp
Philipp Rossak (6):
media: rc: update sunxi-ir driver to get base clock frequency from
devicetree
media: dt: bindings: Update binding documentation for sunxi IR
controller
arm: dts: sun8i: a83t: Add the cir pin for the A83T
arm: dts: sun8i: a83t: Add support for the cir interface
arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
arm: dts: sun8i: h3-h8: ir register size should be the whole memory
block
Documentation/devicetree/bindings/media/sunxi-ir.txt | 3 +++
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
5 files changed, 37 insertions(+), 9 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH] drm/rockchip: analogix_dp: Ensure that the bridge is powered before poking it
From: Andrzej Hajda @ 2017-12-19 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218112831.7990-1-marc.zyngier@arm.com>
On 18.12.2017 12:28, Marc Zyngier wrote:
> Stopping the X display manager on a kevin platform results in the
> following crash:
>
> [ 674.833536] Synchronous External Abort: synchronous external abort (0x96000010) at 0xffff00000c970640
> [ 674.843886] Internal error: : 96000010 [#1] PREEMPT SMP
> [ 674.849744] Modules linked in:
> [ 674.849755] CPU: 1 PID: 86 Comm: kworker/1:1 Not tainted 4.15.0-rc3-00057-gff24f8cf492d-dirty #3
> [ 674.849760] detected fb_set_par error, error code: -16
> [ 674.849761] Hardware name: Google Kevin (DT)
> [ 674.849773] Workqueue: events analogix_dp_psr_work
> [ 674.849778] pstate: 60000005 (nZCv daif -PAN -UAO)
> [ 674.849784] pc : analogix_dp_send_psr_spd+0x8/0x168
> [ 674.849788] lr : analogix_dp_enable_psr+0x54/0x60
> [ 674.849789] sp : ffff000009b2bd60
> [ 674.849790] x29: ffff000009b2bd60 x28: 0000000000000000
> [ 674.849794] x27: ffff000009913d20 x26: ffff00000900fbf0
> [ 674.849797] x25: ffff8000f1b30000 x24: ffff8000f0c21d98
> [ 674.849800] x23: 0000000000000000 x22: ffff8000f7d3aa00
> [ 674.849803] x21: ffff8000f7d36980 x20: ffff8000f0c21c18
> [ 674.849806] x19: ffff8000f0c21db8 x18: 0000000000000001
> [ 674.849809] x17: 0000ffff89f2ed58 x16: ffff000008222908
> [ 674.849812] x15: 0000000000000000 x14: 0000000000000400
> [ 674.849815] x13: 0000000000000400 x12: 0000000000000000
> [ 674.849817] x11: 0000000000001414 x10: 0000000000000a00
> [ 674.849820] x9 : ffff000009b2bbb0 x8 : ffff8000f1b30a60
> [ 674.849823] x7 : 0000000000080000 x6 : 0000000000000001
> [ 674.849826] x5 : 0000000000000010 x4 : 0000000000000007
> [ 674.849829] x3 : 0000000000000002 x2 : ffff00000c970640
> [ 674.849832] x1 : ffff000009b2bd78 x0 : ffff8000f1624018
> [ 674.849836] Process kworker/1:1 (pid: 86, stack limit = 0x0000000083e5f7c3)
> [ 674.849838] Call trace:
> [ 674.849842] analogix_dp_send_psr_spd+0x8/0x168
> [ 674.849844] analogix_dp_psr_work+0x9c/0xa0
> [ 674.849849] process_one_work+0x1cc/0x328
> [ 674.849852] worker_thread+0x50/0x450
> [ 674.849856] kthread+0xf8/0x128
> [ 674.849860] ret_from_fork+0x10/0x18
> [ 674.849864] Code: b9000001 d65f03c0 f9445802 91190042 (b9400042)
>
> Further investigation show that this happens because the the workqueue
> races with the analogix_dp_bridge_disable() call from the core DRM code,
> and end up trying to write to the DP bridge that has already been powered
> down. This result is a very black screen, and a hard reset.
>
> Instead of counting on luck to keep the bridge alive, let's use the
> pm_runtime framework and take a reference on the device when we're about
> to poke it. That is a fairly big hammer, but one that allows the system
> to stay alive across dozens of X start/stop sequences.
Wouldn't be better to cancel the work in analogix_dp_bridge_disable, it
looks safer.
Regards
Andrzej
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 08743ad96cb9..7f2c190f75e7 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -14,6 +14,7 @@
>
> #include <linux/component.h>
> #include <linux/mfd/syscon.h>
> +#include <linux/pm_runtime.h>
> #include <linux/of_device.h>
> #include <linux/of_graph.h>
> #include <linux/regmap.h>
> @@ -113,10 +114,12 @@ static void analogix_dp_psr_work(struct work_struct *work)
> }
>
> mutex_lock(&dp->psr_lock);
> + pm_runtime_get_sync(dp->dev);
> if (dp->psr_state == EDP_VSC_PSR_STATE_ACTIVE)
> analogix_dp_enable_psr(dp->dev);
> else
> analogix_dp_disable_psr(dp->dev);
> + pm_runtime_put_sync(dp->dev);
> mutex_unlock(&dp->psr_lock);
> }
>
>
^ permalink raw reply
* [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-19 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219060918.nr4ojwpmqf6ju6od@sapphire.tkos.co.il>
Hello Baruch,
On Tue, 19 Dec 2017 08:09:18 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miqu?l,
>
> On Tue, Dec 19, 2017 at 01:43:20AM +0100, Miquel RAYNAL wrote:
> > On Mon, 18 Dec 2017 22:33:24 +0200
> > Baruch Siach <baruch@tkos.co.il> wrote:
> > > On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > > > From: Baruch Siach <baruch@tkos.co.il>
> > > >
> > > > Add compatible strings for AP806 and CP110 that are part of the
> > > > Armada 8k/7k line of SoCs.
> > > >
> > > > Add a note on the differences in the size of the control area in
> > > > different bindings. This is an existing difference between the
> > > > Armada 375 binding and the other boards already supported. The
> > > > new AP806 and CP110 bindings are similar to the existing Armada
> > > > 375 in this regard.
> > > >
> > > > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > > > [<miquel.raynal@free-electrons.com>: reword, additional details]
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > > > ---
> > > > .../devicetree/bindings/thermal/armada-thermal.txt | 24
> > > > +++++++++++++++++----- 1 file changed, 19 insertions(+), 5
> > > > deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > index 24aacf8948c5..9b7b2c03cc6f 100644 ---
> > > > a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> > > > @@ -7,17 +7,31 @@ Required properties:
> > > > marvell,armada375-thermal marvell,armada380-thermal
> > > > marvell,armadaxp-thermal
> > > > + marvell,armada-ap806-thermal
> > > > + marvell,armada-cp110-thermal
> > > >
> > > > - reg: Device's register space.
> > > > Two entries are expected, see the examples
> > > > below.
> > > > - The first one is required for the sensor
> > > > register;
> > > > - the second one is required for the control
> > > > register
> > > > - to be used for sensor initialization (a.k.a.
> > > > calibration).
> > > > + The first one points to the status register
> > > > (4B).
> > > > + The second one points to the control registers
> > > > (8B).
> > > > + Note: with legacy bindings, the second entry
> > > > pointed
> > > > + only to the so called "control MSB" ("control
> > > > 1"), was
> > > > + 4B wide and did not let the possibility to
> > > > reach the
> > > > + "control LSB" ("control 0") register. This is
> > > > only
> > > > + allowed for compatibility reasons in Armada
> > > > + 370/375/38x/XP DT nodes.
> > >
> > > "allowed" is not the right term, IMO. Legacy compatibles MUST
> > > point to the MSB control register to preserve compatibility with
> > > existing DTs.
> > >
> > > The original patch had a list of legacy and non-legacy
> > > compatibles. I think we need to keep them.
> >
> > Maybe I should reword this paragraph because we both agree on the
> > meaning:
> >
> > "
> > Note: Legacy bindings are only supported with Armada 370/375/38x/XP
> > compatibles. The second memory resource entry only points to
> > "control MSB/control 1", is 4 bytes wide and is preventing any
> > access to "control LSB/control 0".
> > "
> >
> > Does this sounds better to you?
>
> I think we need to explicitly list the affected compatible strings.
> Something like:
I thought listing the SoCs directly would have been acceptable
but I am really not against listing them explicitly :)
>
> For backwards compatibility reasons, the compatibles
> marvell,armada370-thermal, marvell,armada380-thermal, and
> marvell,armadaxp-thermal must point to "control MSB/control 1",
> with size of 4. All other compatibles must point to "control
> LSB/control 0" with size of 8.
>
> But I think you are right that we can use the size of the control
> registers to tell whether e.g. marvell,armada380-thermal is of the
> old binding of the new one. So maybe the "allow" language is more
> correct. But let's make it explicit to avoid any doubt. How about:
>
> The compatibles marvell,armada370-thermal,
> marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
> "control MSB/control 1", with size of 4 (deprecated binding), or
> point to "control LSB/control 0" with size of 8 (current binding).
> All other compatibles must point to "control LSB/control 0" with size
> of 8.
This version looks good to me!
Thank you,
Miqu?l
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/3] irqchip: irq-bcm2836: add support for DT interrupt polarity
From: Stefan Wahren @ 2017-12-19 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513024752-11246-1-git-send-email-stefan.wahren@i2se.com>
Hi Marc,
Am 11.12.2017 um 21:39 schrieb Stefan Wahren:
> This patch series implements DT polarity support for the 1st level interrupt
> controller.
>
> Stefan Wahren (3):
> dt-bindings: bcm2836-l1-intc: add interrupt polarity support
> irqchip: irq-bcm2836: add support for DT interrupt polarity
> ARM: dts: bcm283x: Define polarity of per-cpu interrupts
>
> .../interrupt-controller/brcm,bcm2836-l1-intc.txt | 4 +-
> arch/arm/boot/dts/bcm2836.dtsi | 14 +++----
> arch/arm/boot/dts/bcm2837.dtsi | 12 +++---
> arch/arm/boot/dts/bcm283x.dtsi | 1 +
> drivers/irqchip/irq-bcm2836.c | 46 +++++++++++++---------
> 5 files changed, 44 insertions(+), 33 deletions(-)
>
is this series okay?
^ permalink raw reply
* [PATCH V3 1/2] dt-bindings: bcm283x: Fix register ranges of bcm2835-i2s
From: Stefan Wahren @ 2017-12-19 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512818795-1441-2-git-send-email-stefan.wahren@i2se.com>
Am 09.12.2017 um 12:26 schrieb Stefan Wahren:
> Since 517e7a1537a ("ASoC: bcm2835: move to use the clock framework")
> the bcm2835-i2s requires a clock as DT property. Unfortunately
> the necessary DT change has never been applied. While we are at it
> also fix the first PCM register range to cover the PCM_GRAY register.
>
> This patch only fixes the affected dt-bindings.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> Reviewed-by: Eric Anholt <eric@anholt.net>
> ---
> Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt | 4 ++--
> Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt | 9 ++++-----
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
> index baf9b34..b6a8cc0 100644
> --- a/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
> @@ -74,8 +74,8 @@ Example:
>
> bcm2835_i2s: i2s at 7e203000 {
> compatible = "brcm,bcm2835-i2s";
> - reg = < 0x7e203000 0x20>,
> - < 0x7e101098 0x02>;
> + reg = < 0x7e203000 0x24>;
> + clocks = <&clocks BCM2835_CLOCK_PCM>;
>
> dmas = <&dma 2>,
> <&dma 3>;
> diff --git a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
> index 65783de..7bb0362 100644
> --- a/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/brcm,bcm2835-i2s.txt
> @@ -2,9 +2,8 @@
>
> Required properties:
> - compatible: "brcm,bcm2835-i2s"
> -- reg: A list of base address and size entries:
> - * The first entry should cover the PCM registers
> - * The second entry should cover the PCM clock registers
> +- reg: Should contain PCM registers location and length.
> +- clocks: the (PCM) clock to use
> - dmas: List of DMA controller phandle and DMA request line ordered pairs.
> - dma-names: Identifier string for each DMA request line in the dmas property.
> These strings correspond 1:1 with the ordered pairs in dmas.
> @@ -16,8 +15,8 @@ Example:
>
> bcm2835_i2s: i2s at 7e203000 {
> compatible = "brcm,bcm2835-i2s";
> - reg = <0x7e203000 0x20>,
> - <0x7e101098 0x02>;
> + reg = <0x7e203000 0x24>;
> + clocks = <&clocks BCM2835_CLOCK_PCM>;
>
> dmas = <&dma 2>,
> <&dma 3>;
gentle ping ...
^ permalink raw reply
* [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support
From: Linu Cherian @ 2017-12-19 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7312293d-8897-95d8-9045-9e97a6c150eb@arm.com>
Hi Marc,
On Mon Dec 18, 2017 at 03:39:22PM +0000, Marc Zyngier wrote:
> Thanks for putting me in the loop Robin.
>
> On 18/12/17 14:48, Robin Murphy wrote:
> > On 10/12/17 02:35, Linu Cherian wrote:
> >> Hi,
> >>
> >>
> >> On Fri Aug 04, 2017 at 03:59:12PM -0400, Neil Leeder wrote:
> >>> This adds a driver for the SMMUv3 PMU into the perf framework.
> >>> It includes an IORT update to support PM Counter Groups.
> >>>
> >>
> >> In one of Cavium's upcoming SOC, SMMU PMCG implementation is such a way
> >> that platform bus id (Device ID in ITS terminmology)is shared with that of SMMU.
> >> This would be a matter of concern for software if the SMMU and SMMU PMCG blocks
> >> are managed by two independent drivers.
> >>
> >> The problem arises when we want to alloc/free MSIs for these devices
> >> using the APIs, platform_msi_domain_alloc/free_irqs.
> >> Platform bus id being same for these two hardware blocks, they end up sharing the same
> >> ITT(Interrupt Translation Table) in GIC ITS and hence alloc, free and management
> >> of this shared ITT becomes a problem when they are managed by two independent
> >> drivers.
> >
> > What is the problem exactly? IIRC resizing a possibly-live ITT is a
> > right pain in the bum to do - is it just that?
>
> Understatement of the day! ;-) Yes, it is a massive headache, and will
> either result in a temporary loss of interrupts (at some point you have
> to unmap the ITT), or with spurious interrupts (you generate interrupts
> for all the MSIs you've blackholed when unmapping the ITT).
Just sharing a thought.
If the firmware, through device tree/ACPI
can provide the following input to the ITS driver,
(For example, as part of msi-parent property in device tree)
1. flag indicating the ITT (Device ID) is being shared
2. the maximum number of vectors that are required to be allocated for this ITT
resizing of ITT and the associated complexities could be avoided.
>
> >
> >> We were looking into the option of keeping the SMMU PMCG nodes as sub nodes under
> >> SMMUv3 node, so that SMMUv3 driver could probe and figure out the total vectors
> >> required for SMMU PMCG devices and make a common platform_msi_domain_alloc/free_irqs
> >> function call for all devices that share the platform bus id.
> >
> > I'm not sure how scalable that approach would be, since it's not
> > entirely obvious how to handle PMCGs associated with named components or
> > root complexes (rather than directly with SMMU instances). We certainly
> > don't want to end up spraying similar PMCG DevID logic around all manner
> > of GPU/accelerator/etc. drivers in future (whilst PMCGs for device TLBs
> > will be expected to have distinct IDs from their host devices, they
> > could reasonably still overlap with other PMCGs/SMMUs).
> >
> >> Would like to know your expert opinion on what would be the right approach
> >> to handle this case ?
> >
> > My gut feeling says the way to deal with this properly is in the ITS
> > code, but I appreciate that that's a lot easier said than done :/
>
> I can revive the hack I once wrote for that (and that was hoping to
> forever forget), but that's pretty disgusting, and subject to the above
> caveat.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Linu cherian
^ 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