* [PATCH v3 0/6] arm: sunxi: IR support for A83T
From: Philipp Rossak @ 2017-12-19 8:07 UTC (permalink / raw)
To: mchehab-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, sean-hENCXIMQXOg,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, andi.shyti-Sze3O3UU22JBDgjK7y7TUQ
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
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
* Re: [PATCH] touchscreen: mms114: add support for mms152
From: Simon Shields @ 2017-12-19 8:04 UTC (permalink / raw)
To: Andi Shyti
Cc: Dmitry Torokhov, linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171219062252.GC25647-8vUhnHFVuGn35fTxX1Dczw@public.gmane.org>
Hi Andi,
Thanks for the review.
On Tue, Dec 19, 2017 at 03:22:52PM +0900, Andi Shyti wrote:
> Hi Simon,
>
> > + if (data->pdata->type == TYPE_MMS152) {
> > + /* MMS152 has no configuration or power on registers */
> > + return 0;
> > + }
> > +
>
> Please drop the brackets here accorting to the
> Documentation/process/coding-style.rst file.
>
> > + pdata->type = (enum mms_type)of_device_get_match_data(dev);
> > +
> > if (of_property_read_u32(np, "x-size", &pdata->x_size)) {
> > dev_err(dev, "failed to get x-size property\n");
> > return NULL;
> > @@ -411,6 +437,7 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
> > if (of_find_property(np, "y-invert", NULL))
> > pdata->y_invert = true;
> >
> > +
>
> Please do not add extra lines
>
> > return pdata;
> > }
> > #else
> > @@ -456,7 +483,15 @@ static int mms114_probe(struct i2c_client *client,
> > data->input_dev = input_dev;
> > data->pdata = pdata;
> >
> > - input_dev->name = "MELFAS MMS114 Touchscreen";
> > + switch (pdata->type) {
> > + case TYPE_MMS114:
> > + input_dev->name = "MELFAS MMS114 Touchscreen";
> > + break;
> > + case TYPE_MMS152:
> > + input_dev->name = "MELFAS MMS152 Touchscreen";
> > + break;
> > + }
> > +
> > input_dev->id.bustype = BUS_I2C;
> > input_dev->dev.parent = &client->dev;
> > input_dev->open = mms114_input_open;
> > @@ -569,7 +604,13 @@ MODULE_DEVICE_TABLE(i2c, mms114_id);
> >
> > #ifdef CONFIG_OF
> > static const struct of_device_id mms114_dt_match[] = {
> > - { .compatible = "melfas,mms114" },
> > + {
> > + .compatible = "melfas,mms114",
> > + .data = (void *)TYPE_MMS114,
> > + }, {
> > + .compatible = "melfas,mms152",
> > + .data = (void *)TYPE_MMS152,
>
> You are not documenting the new "melfas,mms152" compatible in
> Documentation/devicetree/bindings/input/touchscreen/mms114.txt
Yes I am - "melfas,mms152" is added to the documentation
as part of this patch. Is there something wrong with what I've done
there?
>
> Andi
I will send a v2 addressing the style issues.
Cheers,
Simon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-19 7:44 UTC (permalink / raw)
To: Baruch Siach
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171219060918.nr4ojwpmqf6ju6od-MwjkAAnuF3khR1HGirfZ1z4kX+cae0hd@public.gmane.org>
Hello Baruch,
On Tue, 19 Dec 2017 08:09:18 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> 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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > > On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > > > From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > > >
> > > > 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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > > > [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: reword, additional details]
> > > > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > > ---
> > > > .../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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] irqchip: irq-bcm2836: add support for DT interrupt polarity
From: Stefan Wahren @ 2017-12-19 7:02 UTC (permalink / raw)
To: Thomas Gleixner, Jason Cooper, Marc Zyngier, Eric Anholt,
Florian Fainelli, Scott Branden, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, phil-FnsA7b+Nu9XbIbC87yuRow,
Russell King, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513024752-11246-1-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
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?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [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: Liam Girdwood, Mark Brown, Eric Anholt, Florian Fainelli,
Rob Herring, Mark Rutland, kernel, Matthias Reichl, phil
Cc: devicetree, alsa-devel, linux-rpi-kernel, 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@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@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
* Re: [PATCH v3 07/33] nds32: MMU initialization
From: Greentime Hu @ 2017-12-19 6:56 UTC (permalink / raw)
To: Guo Ren
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Mark Rutland, Greg KH
In-Reply-To: <20171218122253.GA19382@gary-OptiPlex-3050>
Hi, Guo Ren:
2017-12-18 20:22 GMT+08:00 Guo Ren <ren_guo@c-sky.com>:
> On Mon, Dec 18, 2017 at 07:21:30PM +0800, Greentime Hu wrote:
>> Hi, Guo Ren:
>>
>> 2017-12-18 17:08 GMT+08:00 Guo Ren <ren_guo@c-sky.com>:
>> > Hi Greentime,
>> >
>> > On Fri, Dec 08, 2017 at 05:11:50PM +0800, Greentime Hu wrote:
>> > [...]
>> >>
>> >> diff --git a/arch/nds32/mm/highmem.c b/arch/nds32/mm/highmem.c
>> > [...]
>> >> +void *kmap(struct page *page)
>> >> +{
>> >> + unsigned long vaddr;
>> >> + might_sleep();
>> >> + if (!PageHighMem(page))
>> >> + return page_address(page);
>> >> + vaddr = (unsigned long)kmap_high(page);
>> > Here should invalid the cpu_mmu_tlb's entry, Or invalid it in the
>> > set_pte().
>> >
>> > eg:
>> > vaddr0 = kmap(page0)
>> > *vaddr0 = val0 //It will cause tlb-miss, and hard-refill to MMU-tlb
>> > kunmap(page0)
>> > vaddr1 = kmap(page1) // Mostly vaddr1 = vaddr0
>> > val = vaddr1; //No tlb-miss and it will get page0's val not page1, because
>> > last expired vaddr0's entry is left in CPU-MMU-tlb.
>> >
>>
>> Thanks.
>> I will add __nds32__tlbop_inv(vaddr); to invalidate this mapping
>> before retrun vaddr.
>
> Sorry, perhaps I'm wrong. See
> kmap->kmap_high->map_new_virtual->get_next_pkmap_nr(color).
>
> Seems pkmap will return the vaddr by vaddr + 1 until
> no_more_pkmaps(), and then flush_all_zero_pkmaps.
> Just kmap_atomic need it, and you've done.
Thanks for double checking this case. :)
As you said, it will flush tlb in the generic code flow.
^ permalink raw reply
* Re: [PATCH v6] mfd: syscon: Add hardware spinlock support
From: Baolin Wang @ 2017-12-19 6:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lee Jones, Rob Herring, Mark Rutland, Mark Brown,
Linux Kernel Mailing List, DTML
In-Reply-To: <CAK8P3a3JTV0z0ua_xbbf8eJFGsgOEai4RC9Ny5-JL80MPuKFSA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 18 December 2017 at 20:44, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Mon, Dec 18, 2017 at 7:54 AM, Baolin Wang <baolin.wang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On 15 December 2017 at 21:13, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>>> On Fri, Dec 15, 2017 at 11:42 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>
>>>>> @@ -87,6 +88,30 @@ static struct syscon *of_syscon_register(struct device_node *np)
>>>>> if (ret)
>>>>> reg_io_width = 4;
>>>>>
>>>>> + ret = of_hwspin_lock_get_id(np, 0);
>>>>> + if (ret > 0) {
>>>>> + syscon_config.hwlock_id = ret;
>>>>> + syscon_config.hwlock_mode = HWLOCK_IRQSTATE;
>>>>> + } else {
>>>>> + switch (ret) {
>>>>> + case -ENOENT:
>>>>> + /* Ignore missing hwlock, it's optional. */
>>>>> + break;
>>>>> + case 0:
>>>>> + /* In case of the HWSPINLOCK is not enabled. */
>>>>> + if (!IS_ENABLED(CONFIG_HWSPINLOCK))
>>>>> + break;
>>>>> +
>>>>> + ret = -EINVAL;
>>>>> + /* fall-through */
>>>>> + default:
>>>>> + pr_err("Failed to retrieve valid hwlock: %d\n", ret);
>>>>> + /* fall-through */
>>>>> + case -EPROBE_DEFER:
>>>>> + goto err_regmap;
>>>>> + }
>>>
>>> The 'case 0' seems odd here, are we sure that this is always a failure?
>>> From the of_hwspin_lock_get_id() definition it looks like zero might
>>> be valid, and the !CONFIG_HWSPINLOCK implementation appears
>>> to be written so that we should consider '0' valid but unused and
>>> silently continue with that. If that is generally not the intended
>>> use, it should probably return -EINVAL or something like that.
>>
>> Yes, 0 is valid for of_hwspin_lock_get_id(), but if we pass 'hwlock id
>> = 0' to regmap, the regmap core will not regard it as a valid hwlock
>> id to request the hwlock and will use default mutex lock instead of
>> hwlock, which will cause problems. Meanwhile if we silently continue
>> with case 0, users will not realize that they set one invalid hwlock
>> id to regmap core, so here we regarded case 0 as one invalid id to
>> print error messages for users.
>
> Something else still seems wrong then: If regmap doesn't accept a zero
> lock-id, then of_hwspin_lock_get_id() should never return that as a
> valid ID, right?
Um, why regmap doesn't accept a zero lock-id, that because regmap will
reguest hwlock depending on the 'regmap_config->hwlock_id' is not
zero, if regmap regard a zero lock-id as valid which will affect other
'struct regmap_config' definition. So users should not assign the zero
lock-id to regmap.
Now of_hwspin_lock_get_id() can return 0 as valid, which depend on
what is the base id registered by hwspinlock driver. So you think we
should not regard 0 as valid from of_hwspin_lock_get_id(), I can try
to send another patch to fix.
But for this patch I still think we need regard the zero lock-id as
invalid and gave error messages to users.
--
Baolin.wang
Best Regards
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] i2c: mediatek: Enable i2c module clock before i2c registers access.
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: srv_heupstream, devicetree, linux-i2c, linux-arm-kernel,
linux-kernel, linux-mediatek, Jun Gao
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Make sure i2c module clock has been enabled before i2c registers
access.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 58d6401..cf23a74 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -861,10 +861,19 @@ static int mtk_i2c_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int mtk_i2c_resume(struct device *dev)
{
+ int ret;
struct mtk_i2c *i2c = dev_get_drvdata(dev);
+ ret = mtk_i2c_clock_enable(i2c);
+ if (ret) {
+ dev_err(dev, "clock enable failed!\n");
+ return ret;
+ }
+
mtk_i2c_init_hw(i2c);
+ mtk_i2c_clock_disable(i2c);
+
return 0;
}
#endif
--
1.8.1.1
^ permalink raw reply related
* [PATCH 2/3] i2c: mediatek: Add i2c compatible for MediaTek MT2712
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jun Gao
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Jun Gao <jun.gao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Add i2c compatible for MT2712. Compare to MT8173 i2c controller,
internal divider of i2c source clock need to be configured for
MT2712 i2c speed calculation.
Signed-off-by: Jun Gao <jun.gao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/i2c/busses/i2c-mt65xx.c | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 09d288c..58d6401 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -61,6 +61,7 @@
#define I2C_DMA_HARD_RST 0x0002
#define I2C_DMA_4G_MODE 0x0001
+#define I2C_DEFAULT_CLK_DIV 5
#define I2C_DEFAULT_SPEED 100000 /* hz */
#define MAX_FS_MODE_SPEED 400000
#define MAX_HS_MODE_SPEED 3400000
@@ -127,6 +128,7 @@ enum I2C_REGS_OFFSET {
OFFSET_DEBUGSTAT = 0x64,
OFFSET_DEBUGCTRL = 0x68,
OFFSET_TRANSFER_LEN_AUX = 0x6c,
+ OFFSET_CLOCK_DIV = 0x70,
};
struct mtk_i2c_compatible {
@@ -136,6 +138,7 @@ struct mtk_i2c_compatible {
unsigned char auto_restart: 1;
unsigned char aux_len_reg: 1;
unsigned char support_33bits: 1;
+ unsigned char timing_adjust: 1;
};
struct mtk_i2c {
@@ -176,6 +179,15 @@ struct mtk_i2c {
.max_num_msgs = 255,
};
+static const struct mtk_i2c_compatible mt2712_compat = {
+ .pmic_i2c = 0,
+ .dcm = 1,
+ .auto_restart = 1,
+ .aux_len_reg = 1,
+ .support_33bits = 1,
+ .timing_adjust = 1,
+};
+
static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = &mt6577_i2c_quirks,
.pmic_i2c = 0,
@@ -183,6 +195,7 @@ struct mtk_i2c {
.auto_restart = 0,
.aux_len_reg = 0,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt6589_compat = {
@@ -192,6 +205,7 @@ struct mtk_i2c {
.auto_restart = 0,
.aux_len_reg = 0,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt7622_compat = {
@@ -201,6 +215,7 @@ struct mtk_i2c {
.auto_restart = 1,
.aux_len_reg = 1,
.support_33bits = 0,
+ .timing_adjust = 0,
};
static const struct mtk_i2c_compatible mt8173_compat = {
@@ -209,9 +224,11 @@ struct mtk_i2c {
.auto_restart = 1,
.aux_len_reg = 1,
.support_33bits = 1,
+ .timing_adjust = 0,
};
static const struct of_device_id mtk_i2c_of_match[] = {
+ { .compatible = "mediatek,mt2712-i2c", .data = &mt2712_compat },
{ .compatible = "mediatek,mt6577-i2c", .data = &mt6577_compat },
{ .compatible = "mediatek,mt6589-i2c", .data = &mt6589_compat },
{ .compatible = "mediatek,mt7622-i2c", .data = &mt7622_compat },
@@ -271,6 +288,9 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
if (i2c->dev_comp->dcm)
writew(I2C_DCM_DISABLE, i2c->base + OFFSET_DCM_EN);
+ if (i2c->dev_comp->timing_adjust)
+ writew(I2C_DEFAULT_CLK_DIV - 1, i2c->base + OFFSET_CLOCK_DIV);
+
writew(i2c->timing_reg, i2c->base + OFFSET_TIMING);
writew(i2c->high_speed_reg, i2c->base + OFFSET_HS);
@@ -725,10 +745,6 @@ static int mtk_i2c_probe(struct platform_device *pdev)
if (!i2c)
return -ENOMEM;
- ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
- if (ret)
- return -EINVAL;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
i2c->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(i2c->base))
@@ -759,6 +775,13 @@ static int mtk_i2c_probe(struct platform_device *pdev)
i2c->adap.timeout = 2 * HZ;
i2c->adap.retries = 1;
+ ret = mtk_i2c_parse_dt(pdev->dev.of_node, i2c);
+ if (ret)
+ return -EINVAL;
+
+ if (i2c->dev_comp->timing_adjust)
+ i2c->clk_src_div *= I2C_DEFAULT_CLK_DIV;
+
if (i2c->have_pmic && !i2c->dev_comp->pmic_i2c)
return -EINVAL;
--
1.8.1.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: i2c: Add MediaTek MT2712 i2c binding
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: srv_heupstream, devicetree, linux-i2c, linux-arm-kernel,
linux-kernel, linux-mediatek, Jun Gao
In-Reply-To: <1513666263-6443-1-git-send-email-jun.gao@mediatek.com>
From: Jun Gao <jun.gao@mediatek.com>
Add MT2712 i2c binding to binding file. Compare to MT8173 i2c
controller, MT2712 has timing adjust registers which can adjust
the internal divider of i2c source clock, SCL duty cycle, SCL
compare point, start(repeated start) and stop time, SDA change
time.
Signed-off-by: Jun Gao <jun.gao@mediatek.com>
---
Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index ff7bf37..e199695 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -5,6 +5,7 @@ The MediaTek's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: value should be either of the following.
"mediatek,mt2701-i2c", "mediatek,mt6577-i2c": for MediaTek MT2701
+ "mediatek,mt2712-i2c": for MediaTek MT2712
"mediatek,mt6577-i2c": for MediaTek MT6577
"mediatek,mt6589-i2c": for MediaTek MT6589
"mediatek,mt7622-i2c": for MediaTek MT7622
--
1.8.1.1
^ permalink raw reply related
* [PATCH 0/3] Add i2c dt-binding and compatible for Mediatek MT2712
From: Jun Gao @ 2017-12-19 6:51 UTC (permalink / raw)
To: Wolfram Sang, Matthias Brugger
Cc: srv_heupstream, devicetree, linux-i2c, linux-arm-kernel,
linux-kernel, linux-mediatek
This patch series based on v4.15-rc1, include MT2712 i2c dt-binding, compatible
and i2c module clock enable.
Jun Gao (3):
dt-bindings: i2c: Add MediaTek MT2712 i2c binding
i2c: mediatek: Add i2c compatible for MediaTek MT2712
i2c: mediatek: Enable i2c module clock before i2c registers access.
Documentation/devicetree/bindings/i2c/i2c-mtk.txt | 1 +
drivers/i2c/busses/i2c-mt65xx.c | 40 ++++++++++++++++++++---
2 files changed, 37 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 2/4] dma: fsl-qdma: add devicetree documentation for qDMA driver.
From: Wen He @ 2017-12-19 6:41 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Wen He
Signed-off-by: Wen He <wen.he_1-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/dma/fsl-qdma.txt | 42 ++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/fsl-qdma.txt
diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
new file mode 100644
index 000000000000..b076177b4863
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
@@ -0,0 +1,42 @@
+* Freescale queue Direct Memory Access Controller(qDMA) Controller
+
+ The qDMA controller transfers blocks of data between one source and one or more
+destinations. The blocks of data transferred can be represented in memory as contiguous
+or non-contiguous using scatter/gather table(s). Channel virtualization is supported
+through enqueuing of DMA jobs to, or dequeuing DMA jobs from, different work
+queues.
+
+* qDMA Controller
+Required properties:
+- compatible :
+ - "fsl,ls1021a-qdma",
+ Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
+- reg : Specifies base physical address(s) and size of the qDMA registers.
+ The region is qDMA control register's address and size.
+- interrupts : A list of interrupt-specifiers, one for each entry in
+ interrupt-names.
+- interrupt-names : Should contain:
+ "qdma-error" - the error interrupt
+ "qdma-queue" - the queue interrupt
+- channels : Number of channels supported by the controller
+- queues : Number of queues supported by driver
+
+Optional properties:
+- big-endian: If present registers and hardware scatter/gather descriptors
+ of the qDMA are implemented in big endian mode, otherwise in little
+ mode.
+
+
+Examples:
+
+ qdma: qdma@8390000 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x0 0x8398000 0x0 0x2000 /* Controller registers */
+ 0x0 0x839a000 0x0 0x2000>; /* Block registers */
+ interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "qdma-error", "qdma-queue";
+ channels = <8>;
+ queues = <2>;
+ big-endian;
+ };
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] touchscreen: mms114: add support for mms152
From: Andi Shyti @ 2017-12-19 6:22 UTC (permalink / raw)
To: Simon Shields; +Cc: Dmitry Torokhov, linux-input, devicetree
In-Reply-To: <20171218124933.1803-1-simon@lineageos.org>
Hi Simon,
> + if (data->pdata->type == TYPE_MMS152) {
> + /* MMS152 has no configuration or power on registers */
> + return 0;
> + }
> +
Please drop the brackets here accorting to the
Documentation/process/coding-style.rst file.
> + pdata->type = (enum mms_type)of_device_get_match_data(dev);
> +
> if (of_property_read_u32(np, "x-size", &pdata->x_size)) {
> dev_err(dev, "failed to get x-size property\n");
> return NULL;
> @@ -411,6 +437,7 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev)
> if (of_find_property(np, "y-invert", NULL))
> pdata->y_invert = true;
>
> +
Please do not add extra lines
> return pdata;
> }
> #else
> @@ -456,7 +483,15 @@ static int mms114_probe(struct i2c_client *client,
> data->input_dev = input_dev;
> data->pdata = pdata;
>
> - input_dev->name = "MELFAS MMS114 Touchscreen";
> + switch (pdata->type) {
> + case TYPE_MMS114:
> + input_dev->name = "MELFAS MMS114 Touchscreen";
> + break;
> + case TYPE_MMS152:
> + input_dev->name = "MELFAS MMS152 Touchscreen";
> + break;
> + }
> +
> input_dev->id.bustype = BUS_I2C;
> input_dev->dev.parent = &client->dev;
> input_dev->open = mms114_input_open;
> @@ -569,7 +604,13 @@ MODULE_DEVICE_TABLE(i2c, mms114_id);
>
> #ifdef CONFIG_OF
> static const struct of_device_id mms114_dt_match[] = {
> - { .compatible = "melfas,mms114" },
> + {
> + .compatible = "melfas,mms114",
> + .data = (void *)TYPE_MMS114,
> + }, {
> + .compatible = "melfas,mms152",
> + .data = (void *)TYPE_MMS152,
You are not documenting the new "melfas,mms152" compatible in
Documentation/devicetree/bindings/input/touchscreen/mms114.txt
Andi
^ permalink raw reply
* Re: [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-19 6:09 UTC (permalink / raw)
To: Miquel RAYNAL
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171219014320.182d2522@xps13>
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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > > From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > >
> > > 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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > > [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: reword, additional details]
> > > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > ---
> > > .../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:
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.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Baruch Siach @ 2017-12-19 5:51 UTC (permalink / raw)
To: Miquel RAYNAL
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171219013233.319365c4@xps13>
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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> 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-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > > ---
> >
> > [...]
> >
> > > + /*
> > > + * 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. But I'm not sure all that is strictly necessary. It would just make sure
that no one introduces a DT with the wrong resource size.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 25/36] nds32: Miscellaneous header files
From: Greentime Hu @ 2017-12-19 5:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime, Linux Kernel Mailing List, linux-arch, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Rob Herring, Networking, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Linus Walleij, Mark Rutland, Greg KH, Guo Ren
In-Reply-To: <CAK8P3a1EOD3WB=c4JybBD5bazhVJ5reuegyA1Hyoj-nPHpsW6g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi, Arnd:
2017-12-18 19:13 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Mon, Dec 18, 2017 at 7:46 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>
>> This patch introduces some miscellaneous header files.
>
>> +static inline void __delay(unsigned long loops)
>> +{
>> + __asm__ __volatile__(".align 2\n"
>> + "1:\n"
>> + "\taddi\t%0, %0, -1\n"
>> + "\tbgtz\t%0, 1b\n"
>> + :"=r"(loops)
>> + :"0"(loops));
>> +}
>> +
>> +static inline void __udelay(unsigned long usecs, unsigned long lpj)
>> +{
>> + usecs *= (unsigned long)(((0x8000000000000000ULL / (500000 / HZ)) +
>> + 0x80000000ULL) >> 32);
>> + usecs = (unsigned long)(((unsigned long long)usecs * lpj) >> 32);
>> + __delay(usecs);
>> +}
>
> Do you have a reliable clocksource that you can read here instead of doing the
> loop? It's generally preferred to have an accurate delay if at all possible, the
> delay loop calibration is only for those architectures that don't have any
> way to observe how much time has passed accurately.
>
We currently only have atcpit100 as clocksource but it is an IP of SoC.
These delay API will be unavailable if we changed to another SoC
unless all these timer driver provided the same APIs.
It may suffer our customers if they forget to port these APIs in their
timer drivers when they try to use nds32 in the first beginning.
Or maybe I can use a CONFIG_USE_ACCURATE_DELAY to keep these 2
implementions for these purposes?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
From: Wenyou.Yang @ 2017-12-19 2:11 UTC (permalink / raw)
To: sakari.ailus, mchehab, robh+dt, mark.rutland
Cc: linux-kernel, Nicolas.Ferre, devicetree, corbet, hverkuil,
linux-arm-kernel, linux-media
In-Reply-To: <1641aa67-b05e-47e2-600c-70b77571b450@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
Hi Sakari,
> -----Original Message-----
> From: Sakari Ailus [mailto:sakari.ailus@iki.fi]
> Sent: 2017年12月14日 4:06
> To: Wenyou Yang - A41535 <Wenyou.Yang@microchip.com>; Mauro Carvalho
> Chehab <mchehab@s-opensource.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>
> Cc: linux-kernel@vger.kernel.org; Nicolas Ferre - M43238
> <Nicolas.Ferre@microchip.com>; devicetree@vger.kernel.org; Jonathan Corbet
> <corbet@lwn.net>; Hans Verkuil <hverkuil@xs4all.nl>; linux-arm-
> kernel@lists.infradead.org; Linux Media Mailing List <linux-
> media@vger.kernel.org>; Songjun Wu <songjun.wu@microchip.com>
> Subject: Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
>
> Hi Wenyou,
>
> Wenyou Yang wrote:
> ...
> > +static int ov7740_start_streaming(struct ov7740 *ov7740) {
> > + int ret;
> > +
> > + if (ov7740->fmt) {
> > + ret = regmap_multi_reg_write(ov7740->regmap,
> > + ov7740->fmt->regs,
> > + ov7740->fmt->reg_num);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (ov7740->frmsize) {
> > + ret = regmap_multi_reg_write(ov7740->regmap,
> > + ov7740->frmsize->regs,
> > + ov7740->frmsize->reg_num);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return __v4l2_ctrl_handler_setup(ov7740->subdev.ctrl_handler);
>
> I believe you're still setting the controls after starting streaming.
Yes, it sees it does so.
The OV7740 sensor generates the stream pixel data at the constant frame rate, no such start or stop control.
>
> --
> Sakari Ailus
> sakari.ailus@iki.fi
Wenyou Yang
[-- Attachment #2: imx7d-sdb.dtb --]
[-- Type: application/octet-stream, Size: 46918 bytes --]
^ permalink raw reply
* Re: [PATCH v4 16/36] nds32: System calls handling
From: Vincent Chen @ 2017-12-19 2:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greentime Hu, Greentime, Linux Kernel Mailing List, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Networking, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Mark Rutland, Greg KH,
ren_guo-Y+KPrCd2zL4AvxtiuMwx3w, Philipp
In-Reply-To: <CAK8P3a2Yas3rWdx_qYx48PECundOzRSKOsqkJnUTzGW86OjJVg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-18 19:19 GMT+08:00 Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>:
> On Mon, Dec 18, 2017 at 7:46 AM, Greentime Hu <green.hu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
>> new file mode 100644
>> index 0000000..90da745
>> --- /dev/null
>> +++ b/arch/nds32/include/uapi/asm/unistd.h
>> @@ -0,0 +1,12 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright (C) 2005-2017 Andes Technology Corporation
>> +
>> +#define __ARCH_WANT_SYNC_FILE_RANGE2
>> +
>> +/* Use the standard ABI for syscalls */
>> +#include <asm-generic/unistd.h>
>> +
>> +/* Additional NDS32 specific syscalls. */
>> +#define __NR_cacheflush (__NR_arch_specific_syscall)
>> +#define __NR__llseek __NR_llseek
>> +__SYSCALL(__NR_cacheflush, sys_cacheflush)
>
> I'm still confused by __NR__llseek here, why do you need that one?
>
Dear Arnd:
We hoped to solve ABI register alignment problem for llseek in glibc
by __NR__llseek.
After checking glibc again, I find glibc has same __NR__llseek macro
and It's better to solve this problem.
So, I will remove this definition in the next version patch.
>> +SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
>> + unsigned long, prot, unsigned long, flags,
>> + unsigned long, fd, unsigned long, pgoff)
>> +{
>> + if (pgoff & (~PAGE_MASK >> 12))
>> + return -EINVAL;
>> +
>> + return sys_mmap_pgoff(addr, len, prot, flags, fd,
>> + pgoff >> (PAGE_SHIFT - 12));
>> +}
>> +
>> +SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len,
>> + unsigned long, prot, unsigned long, flags,
>> + unsigned long, fd, unsigned long, pgoff)
>> +{
>> + if (unlikely(pgoff & ~PAGE_MASK))
>> + return -EINVAL;
>> +
>> + return sys_mmap_pgoff(addr, len, prot, flags, fd,
>> + pgoff >> PAGE_SHIFT);
>> +}
>
> And I don't see why you define sys_mmap() in addition to sys_mmap2().
>
This is my mistake. I will remove it in the next version patch.
> The rest of the syscall handling looks good now.
>
> Arnd
Thanks
Vincent
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
From: Stephen Boyd @ 2017-12-19 1:32 UTC (permalink / raw)
To: Matthias Brugger
Cc: Michael Turquette, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
sean.wang-NuS5LvNUpcJWk0Htik3J/w,
chen.zhong-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <b92fd3bd-c61a-ae58-49ef-8727af065ec1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/14, Matthias Brugger wrote:
> Hi Stephen, Michael,
>
> On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> > The ethsys registers a reset controller, so we need to specify a
> > reset cell. This patch fixes the documentation.
> >
> > Signed-off-by: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > index 7aa3fa167668..6cc7840ff37a 100644
> > --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> > @@ -20,4 +20,5 @@ ethsys: clock-controller@1b000000 {
> > compatible = "mediatek,mt2701-ethsys", "syscon";
> > reg = <0 0x1b000000 0 0x1000>;
> > #clock-cells = <1>;
> > + #reset-cells = <1>;
> > };
> >
>
> Will you take this patch through the clk tree, or shall I take it through my SoC
> tree?
>
It's resets, we are clk maintainers. I'm clkfused.
You can take it, along with my
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
if you like/expect conflicts.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 01/12] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-19 0:43 UTC (permalink / raw)
To: Baruch Siach
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171218203324.ftyqrgjawkujvhmn@tarshish>
Hello Baruch,
On Mon, 18 Dec 2017 22:33:24 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> Hi Miquèl,
>
> On Mon, Dec 18, 2017 at 03:36:32PM +0100, Miquel Raynal wrote:
> > From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> >
> > 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-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: reword, additional details]
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > .../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?
Thank you,
Miquèl
>
> baruch
>
> > -Example:
> > +Examples:
> >
> > + /* Legacy bindings */
> > thermal@d0018300 {
> > compatible = "marvell,armada370-thermal";
> > - reg = <0xd0018300 0x4
> > + reg = <0xd0018300 0x4
> > 0xd0018304 0x4>;
> > };
> > +
> > + ap_thermal: thermal@6f8084 {
> > + compatible = "marvell,armada-ap806-thermal";
> > + reg = <0x6f808C 0x4>,
> > + <0x6f8084 0x8>;
> > + };
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 04/12] thermal: armada: Clarify control registers accesses
From: Miquel RAYNAL @ 2017-12-19 0:32 UTC (permalink / raw)
To: Baruch Siach
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Catalin Marinas, Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, David Sniatkiwicz
In-Reply-To: <20171218203542.msnswjqeyuudyusz@tarshish>
Hello Baruch,
On Mon, 18 Dec 2017 22:35:42 +0200
Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> Hi Miquèl,
>
> 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-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
>
> [...]
>
> > + /*
> > + * 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?
Thanks,
Miquèl
>
> baruch
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 06/12] thermal: armada: Add support for Armada AP806
From: Miquel RAYNAL @ 2017-12-19 0:27 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Catalin Marinas,
Will Deacon, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, Baruch Siach,
David Sniatkiwicz
In-Reply-To: <87y3m0hvik.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello Gregory,
Thank you for reviewing the series.
On Mon, 18 Dec 2017 17:05:07 +0100
Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Miquel,
>
> On lun., déc. 18 2017, Miquel Raynal
> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> >
> > The AP806 component is integrated in the Armada 8K and 7K lines of
> > processors.
> >
> > The thermal sensor sample field on the status register is a signed
> > value. Extend armada_get_temp() and the driver structure to handle
> > signed values.
> >
> > Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
> > [<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: Changes when applying over the
> > previous patches, including the register names changes, also
> > switched the coefficients values to s64 instead of unsigned long to
> > deal with negative values and used do_div instead of the
> > traditionnal '/'] Signed-off-by: Miquel Raynal
> > <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> I am just a little concerned by the fac that the value pass though
> get_temp() is an int and now the intermediate calculation are in
> s64. But maybe I'm too picky for this,
I know, but I thought having a temporary s64 variable and casting it
when setting *temp would have been exactly the same so I decided to let
it that way, but if you have something in mind (maybe a check that a
cast into a smaller type is valid? or limiting the temperature to
some boundaries?) I can update.
Thanks,
Miquèl
>
> Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> Gregory
>
>
> > ---
> > drivers/thermal/armada_thermal.c | 80
> > ++++++++++++++++++++++++++++++++-------- 1 file changed, 65
> > insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 198485fa77f2..ec29ea76b818
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -47,6 +47,11 @@
> > #define CONTROL0_OFFSET 0x0
> > #define CONTROL1_OFFSET 0x4
> >
> > +/* TSEN refers to the temperature sensors within the AP */
> > +#define CONTROL0_TSEN_START BIT(0)
> > +#define CONTROL0_TSEN_RESET BIT(1)
> > +#define CONTROL0_TSEN_ENABLE BIT(2)
> > +
> > struct armada_thermal_data;
> >
> > /* Marvell EBU Thermal Sensor Dev Structure */
> > @@ -66,15 +71,17 @@ struct armada_thermal_data {
> > bool (*is_valid)(struct armada_thermal_priv *);
> >
> > /* Formula coeficients: temp = (b - m * reg) / div */
> > - unsigned long coef_b;
> > - unsigned long coef_m;
> > - unsigned long coef_div;
> > + s64 coef_b;
> > + s64 coef_m;
> > + u32 coef_div;
> > bool inverted;
> > + bool signed_sample;
> >
> > /* Register shift and mask to access the sensor
> > temperature */ unsigned int temp_shift;
> > unsigned int temp_mask;
> > u32 is_valid_bit;
> > + bool needs_control0;
> > };
> >
> > static void armadaxp_init_sensor(struct platform_device *pdev,
> > @@ -154,6 +161,18 @@ static void armada380_init_sensor(struct
> > platform_device *pdev, }
> > }
> >
> > +static void armada_ap806_init_sensor(struct platform_device *pdev,
> > + struct armada_thermal_priv
> > *priv) +{
> > + u32 reg;
> > +
> > + reg = readl_relaxed(priv->control0);
> > + reg &= ~CONTROL0_TSEN_RESET;
> > + reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> > + writel(reg, priv->control0);
> > + msleep(10);
> > +}
> > +
> > static bool armada_is_valid(struct armada_thermal_priv *priv)
> > {
> > u32 reg = readl_relaxed(priv->status);
> > @@ -165,8 +184,8 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> > {
> > struct armada_thermal_priv *priv = thermal->devdata;
> > - unsigned long reg;
> > - unsigned long m, b, div;
> > + u32 reg, div;
> > + s64 sample, b, m;
> >
> > /* Valid check */
> > if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> > @@ -177,6 +196,11 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal,
> > reg = readl_relaxed(priv->status);
> > reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask;
> > + if (priv->data->signed_sample)
> > + /* The most significant bit is the sign bit */
> > + sample = sign_extend32(reg,
> > fls(priv->data->temp_mask) - 1);
> > + else
> > + sample = reg;
> >
> > /* Get formula coeficients */
> > b = priv->data->coef_b;
> > @@ -184,9 +208,12 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, div = priv->data->coef_div;
> >
> > if (priv->data->inverted)
> > - *temp = ((m * reg) - b) / div;
> > + *temp = (m * sample) - b;
> > else
> > - *temp = (b - (m * reg)) / div;
> > + *temp = b - (m * sample);
> > +
> > + do_div(*temp, div);
> > +
> > return 0;
> > }
> >
> > @@ -198,8 +225,8 @@ static const struct armada_thermal_data
> > armadaxp_data = { .init_sensor = armadaxp_init_sensor,
> > .temp_shift = 10,
> > .temp_mask = 0x1ff,
> > - .coef_b = 3153000000UL,
> > - .coef_m = 10000000UL,
> > + .coef_b = 3153000000ULL,
> > + .coef_m = 10000000ULL,
> > .coef_div = 13825,
> > };
> >
> > @@ -209,8 +236,8 @@ static const struct armada_thermal_data
> > armada370_data = { .is_valid_bit = BIT(9),
> > .temp_shift = 10,
> > .temp_mask = 0x1ff,
> > - .coef_b = 3153000000UL,
> > - .coef_m = 10000000UL,
> > + .coef_b = 3153000000ULL,
> > + .coef_m = 10000000ULL,
> > .coef_div = 13825,
> > };
> >
> > @@ -220,8 +247,8 @@ static const struct armada_thermal_data
> > armada375_data = { .is_valid_bit = BIT(10),
> > .temp_shift = 0,
> > .temp_mask = 0x1ff,
> > - .coef_b = 3171900000UL,
> > - .coef_m = 10000000UL,
> > + .coef_b = 3171900000ULL,
> > + .coef_m = 10000000ULL,
> > .coef_div = 13616,
> > };
> >
> > @@ -231,12 +258,26 @@ static const struct armada_thermal_data
> > armada380_data = { .is_valid_bit = BIT(10),
> > .temp_shift = 0,
> > .temp_mask = 0x3ff,
> > - .coef_b = 1172499100UL,
> > - .coef_m = 2000096UL,
> > + .coef_b = 1172499100ULL,
> > + .coef_m = 2000096ULL,
> > .coef_div = 4201,
> > .inverted = true,
> > };
> >
> > +static const struct armada_thermal_data armada_ap806_data = {
> > + .is_valid = armada_is_valid,
> > + .init_sensor = armada_ap806_init_sensor,
> > + .is_valid_bit = BIT(16),
> > + .temp_shift = 0,
> > + .temp_mask = 0x3ff,
> > + .coef_b = -150000LL,
> > + .coef_m = 423ULL,
> > + .coef_div = 1,
> > + .inverted = true,
> > + .signed_sample = true,
> > + .needs_control0 = true,
> > +};
> > +
> > static const struct of_device_id armada_thermal_id_table[] = {
> > {
> > .compatible = "marvell,armadaxp-thermal",
> > @@ -255,6 +296,10 @@ static const struct of_device_id
> > armada_thermal_id_table[] = { .data = &armada380_data,
> > },
> > {
> > + .compatible = "marvell,armada-ap806-thermal",
> > + .data = &armada_ap806_data,
> > + },
> > + {
> > /* sentinel */
> > },
> > };
> > @@ -296,6 +341,11 @@ static int armada_thermal_probe(struct
> > platform_device *pdev) */
> > if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> > /* ->control0 unavailable in this configuration */
> > + if (priv->data->needs_control0) {
> > + dev_err(&pdev->dev, "No access to control0
> > register\n");
> > + return -EINVAL;
> > + }
> > +
> > priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > } else {
> > priv->control0 = control + CONTROL0_OFFSET;
> > --
> > 2.11.0
> >
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Rafael J. Wysocki @ 2017-12-19 0:26 UTC (permalink / raw)
To: Dave Gerlach
Cc: Rafael J. Wysocki, Viresh Kumar, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Linux OMAP Mailing List, Linux PM,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren,
Nishanth Menon
In-Reply-To: <abe0efc0-6dfc-e9b0-c535-aa1a48bf1a6b-l0cyMroinI0@public.gmane.org>
On Mon, Dec 18, 2017 at 8:25 PM, Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> wrote:
> Rafael,
> On 12/16/2017 04:52 AM, Rafael J. Wysocki wrote:
>> On Fri, Dec 15, 2017 at 3:29 PM, Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> wrote:
>>>> Document the devicetree bindings that describe Texas Instruments
>>>> opp-supply which allow a platform to describe multiple regulators and
>>>> additional information, such as registers containing data needed to
>>>> program aforementioned regulators.
>>>>
>>>> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
>>>
>>> I need an ACK from Rob on this one.
>>
>> Actually, how this (and the next patch) is related to the [1-2/4]?
>>
>
> The main goal of this series is to add support for scaling the multiple
> regulators needed for the CPU on these TI platforms. The OPP core supports
> multiple regulators but only to the point that it can associate a list of
> regulators to a device. It still by default only scales the normal vdd regulator
> when doing a rate transition. Because of this, we must define our own method of
> doing rate transitions to take the references to our regulators held in the OPP
> core and scale them in the proper sequence depending on what the platform needs.
>
> So to describe the purpose of each patch and their relation to each other:
>
> Patch 1: We must be able to defer the ti-cpufreq driver now that we look for
> regulators during probe as they likely won't be ready when we probe.
>
> Patch 2: Tell the OPP core about regulators needed for TI CPUFreq operation
> using the OPP core. This doesn't actually do anything besides place them in a
> list at this point because the OPP core can't know how TI platforms needs them
> scaled in relation to each other. Placing the regulator definition in ti-cpufreq
> driver ensures they are registered with opp core before cpufreq-dt probes (which
> is triggered at the end of ti-cpufreq probe) and actually makes the opp core get
> the regulators.
>
> Patch 3: Binding doc for patch 4 driver.
>
> Patch 4: TI OPP supply driver which understands how to actually make use of the
> two regulators that the OPP core now has a reference to. This overrides the
> standard opp_set_rate function to let us scale frequency and voltage as needed
> for TI platforms.
Thanks for the explanation, I've applied the series.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 6/6] phy: renesas: rcar-gen3-usb2: add gpio handling
From: Rob Herring @ 2017-12-19 0:09 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: kishon@ti.com, mark.rutland@arm.com, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <SG2PR06MB0981CC4061F538B7ADFE48FDD80E0@SG2PR06MB0981.apcprd06.prod.outlook.com>
On Sun, Dec 17, 2017 at 11:16 PM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> Hi Rob,
>
> Thank you for your comments!
>
>> -----Original Message-----
>> From: Rob Herring, Sent: Sunday, December 17, 2017 3:05 AM
>>
>> On Fri, Dec 15, 2017 at 02:45:26PM +0900, Yoshihiro Shimoda wrote:
>> > Some R-Car SoCs (e.g. R-Car D3) doesn't have dedicated pins of VBUS
>> > and ID. So, they may be connected to gpio pins. To handle the gpio
>> > pins, this patch adds the handling of VBUS and ID pins instead of
>> > dedicated pins.
>> >
>> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> > ---
>> > .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 +
>> > drivers/phy/renesas/phy-rcar-gen3-usb2.c | 77 ++++++++++++++++++++--
>> > 2 files changed, 72 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
>> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
>> > index 99b651b..999a6ef 100644
>> > --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
>> > +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
>> > @@ -27,6 +27,8 @@ channel as USB OTG:
>> > - interrupts: interrupt specifier for the PHY.
>> > - vbus-supply: Phandle to a regulator that provides power to the VBUS. This
>> > regulator will be managed during the PHY power on/off sequence.
>> > +- vbus-gpios: use gpio to control vbus instead of dedicated pin.
>>
>> How does this relate to vbus-supply? A gpio-regulator doesn't work here?
>
> Thank you for the pointed out. You're correct. A gpio-regulator can work intead of "vbus-gpios".
> So, I will drop this.
>
>> > +- id-gpios: use gpio to detect id instead of dedicated pin.
>>
>> These aren't part of the phy, but really belong in a connector node.
>
> I'm afraid but I don't understand "a connector node" mean.
> Is it an extcon device for instance?
> If so, I'll try to use extcon-usb-gpio.c instead of own gpio handling on the driver.
No, extcon binding has a lot of Linuxisms in it. I mean something like
hdmi-connector binding. There's been some attempts[1] for USB
connectors, but nothing finalized.
Rob
[1] https://www.spinics.net/lists/linux-usb/msg161104.html
^ permalink raw reply
* Re: [PATCH 4/6] rpmsg: glink: Expose rpmsg name attr for glink
From: Stephen Boyd @ 2017-12-18 22:48 UTC (permalink / raw)
To: Chris Lew, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
david.brown-QSEj5FYQhm4dnm+yROfE0A
Cc: aneela-sgV2jX0FEOL9JmXXK+q4OQ,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1513634534-22861-5-git-send-email-clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 12/18/2017 02:02 PM, Chris Lew wrote:
> Expose the name field as an attr so clients listening to uevents for
> rpmsg can identify the edge the events correspond to.
>
> Signed-off-by: Chris Lew <clew-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/rpmsg/qcom_glink_native.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c
> index 786f2eca01f1..a897ccea3098 100644
> --- a/drivers/rpmsg/qcom_glink_native.c
> +++ b/drivers/rpmsg/qcom_glink_native.c
> @@ -1558,6 +1558,22 @@ static void qcom_glink_work(struct work_struct *work)
> }
> }
>
> +static ssize_t rpmsg_name_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct rpmsg_device *rpdev = to_rpmsg_device(dev);
> + struct qcom_glink_device *gdev = to_glink_device(rpdev);
> +
> + return snprintf(buf, RPMSG_NAME_SIZE, "%s\n", gdev->glink->name);
> +}
> +static DEVICE_ATTR_RO(rpmsg_name);
> +
> +static struct attribute *qcom_glink_attrs[] = {
const?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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