* [PATCH] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Sanchayan Maity @ 2016-11-10 11:45 UTC (permalink / raw)
To: shawnguo
Cc: stefan, linux-arm-kernel, devicetree, linux-kernel,
Sanchayan Maity
Enable DMA for DSPI2 and DSPI3 on Vybrid.
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 000550f..e9d2847 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -573,6 +573,9 @@
clocks = <&clks VF610_CLK_DSPI2>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 10>,
+ <&edma1 0 11>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -585,6 +588,9 @@
clocks = <&clks VF610_CLK_DSPI3>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 12>,
+ <&edma1 0 13>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v3 00/10] Add DT support for ohci-da8xx
From: Greg KH @ 2016-11-10 12:02 UTC (permalink / raw)
To: Axel Haslam
Cc: Alan Stern, Sekhar Nori, Kevin Hilman, David Lechner, robh+dt,
devicetree, linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <CAKXjFTN04Wz5jsaHsyvDD7G8QqXQvCE4D-YbHtGT=jUqELiS_w@mail.gmail.com>
On Tue, Nov 08, 2016 at 05:37:41PM +0100, Axel Haslam wrote:
> Hi,
>
> On Mon, Nov 7, 2016 at 9:39 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> > The purpose of this patch series is to add DT support for the davinci
> > ohci driver.
> >
>
> To make it easier to review. I will split the arch/arm and driver
> patches into separate series.
I don't think it's easier, as now I have no idea what order, or what
tree it should go through :(
I'm guessing not mine, so all are now deleted from my patch queue...
greg k-h
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-10 12:11 UTC (permalink / raw)
To: Joel Holdsworth, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Clifford Wolf
In-Reply-To: <d3af549a-0f68-7511-ad38-b9ec8aab62ca-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On 11/09/2016 07:54 PM, Joel Holdsworth wrote:
> On 09/11/16 11:39, Marek Vasut wrote:
>> On 11/09/2016 07:37 PM, Joel Holdsworth wrote:
>>> On 09/11/16 05:01, Marek Vasut wrote:
>>>> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>>>>> On the whole, I don't think the zero-length transfers are too
>>>>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>>>>
>>>>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>>>>
>>>>>> Does that work with *all* SPI controllers?
>>>>>>
>>>>>
>>>>> It does not - no. See my other email.
>>>>
>>>> And is that line an actual CS of that lattice chip or a generic input
>>>> which almost works like CS?
>>>>
>>>
>>> I mean a generic output vs. a special CS output built into the SPI
>>> master of the application processor. Take a look at how spi_set_cs(..)
>>> works:
>>
>> No. I am asking whether the signal which is INPUT on the iCE40 side is
>> really a chipselect signal for the SPI bus OR something which mostly
>> behaves/looks like a chipselect but is not really a chipselect.
>
> Oh I see. The SS_B line is the SPI SlaveSelect for the configuration port.
>
> This is the text from the datasheet:
>
> "SPI Slave Select. Active Low. Includes an internal weak pull-up
> resistor to VCC_SPI during configuration. During configuration, the
> logic level sampled on this pin deter-mines the configuration mode used
> by the iCE40 device. An input when sampled at the start of
> configuration. An input when in SPI Peripheral configuration mode
> (SPI_SS_B = Low). An output when in Master SPI Flash configuration mode."
>
> So yes - it is a "real" SPI chip-select line.
OK, thanks for checking.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Laurent Pinchart @ 2016-11-10 12:15 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
tomi.valkeinen
In-Reply-To: <ad052b0f-0ece-4241-3e06-87905a9cf2c7@ti.com>
Hi Jyri,
On Thursday 10 Nov 2016 11:16:53 Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
> > On Wednesday 02 Nov 2016 18:32:16 Jyri Sarha wrote:
> >> Add very basic ti-ftp410 HDMI transmitter driver. The only feature
> >> separating this from a completely dummy bridge is the DDC i2c
> >> support. However, other HW specific features may be added later when
> >> needed. For instance there is a set of registers behind i2c if it is
> >> connected. The implementations is tested against my new tilcdc bridge
> >> support and works with BeagleBone DVI-D Cape Rev A3. A DT binding
> >> document is also added.
> >>
> >> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> >> ---
> >>
> >> .../bindings/display/bridge/ti,tfp410.txt | 30 ++++
> >> drivers/gpu/drm/bridge/Kconfig | 7 +
> >> drivers/gpu/drm/bridge/Makefile | 1 +
> >> drivers/gpu/drm/bridge/ti-tfp410.c | 199 +++++++++++++++
> >> 4 files changed, 237 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file
> >> mode 100644
> >> index 0000000..dc93713
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> @@ -0,0 +1,30 @@
> >> +TFP410 HDMI/DVI bridge bindings
> >
> > I'd name the document "TI TFP410 DVI Transmitter". DVI bridge doesn't tell
> > whether the device is a receiver or transmitter.
> >
> >> +Required properties:
> >> + - compatible: "ti,tfp410"
> >
> > The device is an I2C slave, it should have a reg property. Given that the
> > chip can be used without being controlled through I2C, the reg property
> > should be optional. You should document this clearly, and explain how the
> > DT node can be instantiated as a child of an I2C controller when the I2C
> > interface is used, or in other parts of the device tree otherwise.
> >
> >> +Optional properties:
> >> + - ddc-i2c: phandle of an I2C controller used for DDC EDID probing
> >
> > The TFP410 doesn't handle DDC, this property should be part of the
> > connector node.
> >
> >> +Optional subnodes:
> >> + - video input: this subnode can contain a video input port node
> >> + to connect the bridge to a display controller output (See this
> >> + documentation [1]).
> >
> > You also need an output port for the DVI output. Those two ports should be
> > required, not optional.
>
> Ok. So I need another device node. Should I create some specific
> compatible string for connectors behind tfp410, or a generic DVI/HDMI
> connector with optional ddc-i2c phandle?
The generic DVI/HDMI connector bindings should work fine.
> The implementation side is not so critical, because it more easily
> changed, but should I create an independent generic platform-device
> driver for such DVI/HDMI connector or just implement the connector side
> within tfp410 driver?
Longer term I'd like to go for connector drivers, but it might take a bit of
infrastructure work. If you can give it a try it would be great ! Otherwise
I'm fine with handling that in the tfp410 driver for now.
> >> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >> +
> >> +Example:
> >> + hdmi-bridge {
> >> + compatible = "ti,tfp410";
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@0 {
> >> + reg = <0>;
> >> + bridge_in: endpoint {
> >> + remote-endpoint = <&dc_out>;
> >> + };
> >> + };
> >> + };
> >> + };
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Tomi Valkeinen @ 2016-11-10 12:16 UTC (permalink / raw)
To: Jyri Sarha, Laurent Pinchart
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski
In-Reply-To: <ad052b0f-0ece-4241-3e06-87905a9cf2c7@ti.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 3032 bytes --]
On 10/11/16 11:16, Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
>> Hi Jyri,
>>
>> Thank you for the patch.
>>
>> On Wednesday 02 Nov 2016 18:32:16 Jyri Sarha wrote:
>>> Add very basic ti-ftp410 HDMI transmitter driver. The only feature
>>> separating this from a completely dummy bridge is the DDC i2c
>>> support. However, other HW specific features may be added later when
>>> needed. For instance there is a set of registers behind i2c if it is
>>> connected. The implementations is tested against my new tilcdc bridge
>>> support and works with BeagleBone DVI-D Cape Rev A3. A DT binding
>>> document is also added.
>>>
>>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>>> ---
>>> .../bindings/display/bridge/ti,tfp410.txt | 30 ++++
>>> drivers/gpu/drm/bridge/Kconfig | 7 +
>>> drivers/gpu/drm/bridge/Makefile | 1 +
>>> drivers/gpu/drm/bridge/ti-tfp410.c | 199 ++++++++++++++++++
>>> 4 files changed, 237 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt create mode
>>> 100644 drivers/gpu/drm/bridge/ti-tfp410.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>>> b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file
>>> mode 100644
>>> index 0000000..dc93713
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>>> @@ -0,0 +1,30 @@
>>> +TFP410 HDMI/DVI bridge bindings
>>
>> I'd name the document "TI TFP410 DVI Transmitter". DVI bridge doesn't tell
>> whether the device is a receiver or transmitter.
>>
>>> +Required properties:
>>> + - compatible: "ti,tfp410"
>>
>> The device is an I2C slave, it should have a reg property. Given that the chip
>> can be used without being controlled through I2C, the reg property should be
>> optional. You should document this clearly, and explain how the DT node can be
>> instantiated as a child of an I2C controller when the I2C interface is used,
>> or in other parts of the device tree otherwise.
>>
>>> +Optional properties:
>>> + - ddc-i2c: phandle of an I2C controller used for DDC EDID probing
>>
>> The TFP410 doesn't handle DDC, this property should be part of the connector
>> node.
>>
>>> +Optional subnodes:
>>> + - video input: this subnode can contain a video input port node
>>> + to connect the bridge to a display controller output (See this
>>> + documentation [1]).
>>
>> You also need an output port for the DVI output. Those two ports should be
>> required, not optional.
>>
>
> Ok. So I need another device node. Should I create some specific
> compatible string for connectors behind tfp410, or a generic DVI/HDMI
> connector with optional ddc-i2c phandle?
omapdrm uses connector nodes. See, for example, pandaboard's dts files.
It has TFP410 and a connector node. With omap specific drivers, for now,
but that's another matter.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-10 12:36 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, Gabriele Paoloni, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org,
kantyzc@163.com, linux-serial@vger.kernel.org, catalin.mar
In-Reply-To: <17821285.aIcTyCGn5n@wuerfel>
Hi, Arnd,
On 2016/11/10 17:12, Arnd Bergmann wrote:
> On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
>> On 2016/11/10 5:34, Arnd Bergmann wrote:
>>> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
>>>>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
>>>>>> + /*
>>>>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
>>>>> indirectIO.
>>>>>> + * It will separate indirectIO range from pci host bridge to
>>>>>> + * avoid the possible PIO conflict.
>>>>>> + * Set the indirectIO range directly here.
>>>>>> + */
>>>>>> + lpcdev->io_ops.start = 0;
>>>>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
>>>>>> + lpcdev->io_ops.devpara = lpcdev;
>>>>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
>>>>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
>>>>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
>>>>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
>>>>>
>>>>> I have to look at patch 2 in more detail again, after missing a few
>>>>> review
>>>>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
>>>>> range here, and would hope that we can just go through the same
>>>>> assignment of logical port ranges that we have for PCI buses,
>>>>> decoupling
>>>>> the bus addresses from the linux-internal ones.
>>>>
>>>> The point here is that we want to avoid any conflict/overlap between
>>>> the LPC I/O space and the PCI I/O space. With the assignment above
>>>> we make sure that LPC never interfere with PCI I/O space.
>>>
>>> But we already abstract the PCI I/O space using dynamic registration.
>>> There is no need to hardcode the logical address for ISA, though
>>> I think we can hardcode the bus address to start at zero here.
>>
>> Do you means that we can pick up the maximal I/O address from all children's
>> device resources??
>
> The driver should not look at the resources of its children, just
> register a range of addresses dynamically, as I suggested in an
> earlier review.
>
Sorry! I can't catch your idea yet:(
When to register the I/O range? Is it done just after the successfully
of_translate_address() during the children scanning?
If yes, when a child is scanning, there is no range data in arm64_extio_ops. The
addr_is_indirect_io() calling in of_get_isa_indirect_io() don't need. All we can
check is just whether the address to be translated is IO and is under a parent
device which has no 'ranges' property.
>
> Your current version has
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr, value, sizeof(type)); \
>
> Instead, just subtract the start of the range from the logical
> port number to transform it back into a bus-local port number:
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr - arm64_extio_ops->start, value, sizeof(type)); \
>
I think there is some information needed sync.
In the old patch-set, we don't bypass the pci_address_to_pio() after
successfully of_translate_address(). In this way, we don't need to reserve any
PIO space for our LPC since the logical port are from the same mapping
algorithm. Based on this way, the port number in the device resource is logical
one, then we need to subtract the start of the resource to get back the
bus-local port.
>From V3, we don't apply the mapping based on pci_address_to_pio(), the
of_translate_address() return the bus-local port directly and store into
relevant device resource. So, in the current arm64_extio_ops->pfout(), the
reverse translation don't need anymore. The input "addr" is bus-local port now.
Thanks,
Zhichang
> We know that the ISA/LPC bus can only have up to 65536 ports,
> so you can register all of those, or possibly limit it further to
> 1024 or 4096 ports, whichever matches the bus implementation.
>
> Arnd
>
> .
>
^ permalink raw reply
* Re: [PATCH v6] clk: renesas: cpg-mssr: add R8A7743 support
From: Geert Uytterhoeven @ 2016-11-10 12:52 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Michael Turquette, linux-clk, Stephen Boyd, Rob Herring,
Mark Rutland, devicetree@vger.kernel.org, Linux-Renesas,
Simon Horman
In-Reply-To: <2376126.1sNxSm4GUB@wasted.cogentembedded.com>
Hi Sergei,
On Tue, Nov 8, 2016 at 10:21 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add RZ/G1M (R8A7743) Clock Pulse Generator / Module Standby and Software
> Reset support, using the CPG/MSSR driver core and the common R-Car Gen2
> (and RZ/G) code.
>
> Based on the proof-of-concept R8A7791 CPG/MSSR patch by Geert Uytterhoeven
> <geert+renesas@glider.be>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> This patch is against the 'clk-next' branch of CLK group's 'linux.git' repo.
> It depends on the common R-Car gen2 (and RZ/G) support just posted.
>
> Changes in version 6:
> - passed the PLL0 divisor to rcar_gen2_cpg_init();
> - undid the version 5 changes.
Thanks!
Will queue with the following trivial changes:
- pass cpg_mode to rcar_gen2_cpg_init(),
- sort clock names in DT bindings,
- reformat tables for easier comparison with other clock drivers.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
* Re: [PATCH v4] clk: renesas: cpg-mssr: add R8A7745 support
From: Geert Uytterhoeven @ 2016-11-10 12:53 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Michael Turquette, linux-clk, Stephen Boyd, Rob Herring,
Mark Rutland, devicetree@vger.kernel.org, Linux-Renesas,
Simon Horman
In-Reply-To: <4179265.sjm4z2joGl@wasted.cogentembedded.com>
On Tue, Nov 8, 2016 at 10:25 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add RZ/G1E (R8A7745) Clock Pulse Generator / Module Standby and Software
> Reset support, using the CPG/MSSR driver core and the common R-Car Gen2
> (and RZ/G) code.
>
> Based on the proof-of-concept R8A7791 CPG/MSSR patch by Geert Uytterhoeven
> <geert+renesas@glider.be>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> This patch is against the 'clk-next' branch of CLK group's 'linux.git' repo
> plus the R8A7743 clock driver patch. It depends on the common R-Car gen2 (and
> RZ/G) support just posted.
>
> Changes in version 4:
> - changed the Z2 clock's divisor to 1;
> - passed the PLL0 divisor to rcar_gen2_cpg_init();
> - renamed the ACP clock to CPEX;
> - removed the thermal module clock.
Thanks!
Will queue with the following trivial changes:
- pass cpg_mode to rcar_gen2_cpg_init(),
- sort clock names in DT bindings,
- reformat tables for easier comparison with other clock drivers.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
* RE: [PATCH v2 3/3] clocksource: Add clockevent support to NPS400 driver
From: Noam Camus @ 2016-11-10 13:00 UTC (permalink / raw)
To: Daniel Lezcano
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Vineet Gupta
In-Reply-To: <1850b6f7-3901-1065-5f35-d738f76fb218@linaro.org>
>From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
>Sent: Thursday, November 10, 2016 12:34 PM
>>> give a correct result without a dmesg log ?
>> [root@192.168.8.2 /]$ [root@192.168.8.2 /]$ taskset 65536 time sleep 2
>> & taskset 131072 time sleep 3
>Thanks for providing the numbers.
>So there is no weird messages in dmesg ?
Yes, no weird messages, all seem normal.
>> real 0m 2.54s
>> user 0m 0.04s
>> sys 0m 0.14s
>> real 0m 3.47s
>> user 0m 0.00s
>> sys 0m 0.15s
>> [1]+ Done taskset 65536 time sleep 2
>>
>> Seem OK to me.
>I'm not sure of that.
>2.54 instead of 2
>3.47 instead of 3
>0.02 time drift could be acceptable but 0.54 or 0.47 is too much.
>And 0.15 in sys also a big number AFAICT.
>Is the system in NO_HZ ?
We are handling system with NOHZ_FULL
This was run under simulation and result are reasonable (indeed not perfect) AFAICT.
-Noam
^ permalink raw reply
* [RFC] Documentation: media, leds: move IR LED remote controllers from media to LED
From: Andi Shyti @ 2016-11-10 13:26 UTC (permalink / raw)
To: Rob Herring, Jacek Anaszewski, Mauro Carvalho Chehab
Cc: linux-leds, linux-media, devicetree, Andi Shyti
Hi,
this is purely a request for comments after a discussion had with
Rob and Jacek [*] about where to place the ir leds binding. Rob wants
the binding to be under led, while Jacek wants it in media...
"Ubi maior minor cessat": it goes to LED and they can be organized
in a subdirectory.
Standing to Rob "Bindings are grouped by types of h/w and IR LEDs
are a type of LED": all remote controllers have an IR LED as core
device, even though the framework is under drivers/media/rc/, thus
they naturally belong to the LED binding group.
Please, let me know if this is the right approach.
Thanks,
Andi
[*] https://lkml.org/lkml/2016/9/12/380
https://lkml.org/lkml/2016/11/9/622
---
.../devicetree/bindings/{media => leds/ir-leds}/gpio-ir-receiver.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/hix5hd2-ir.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/img-ir-rev1.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/meson-ir.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/nokia,n900-ir | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/st-rc.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/sunxi-ir.txt | 0
7 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/gpio-ir-receiver.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/hix5hd2-ir.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/img-ir-rev1.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/meson-ir.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/nokia,n900-ir (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/st-rc.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/sunxi-ir.txt (100%)
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/leds/ir-leds/gpio-ir-receiver.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/gpio-ir-receiver.txt
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/leds/ir-leds/hix5hd2-ir.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/hix5hd2-ir.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/hix5hd2-ir.txt
diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt b/Documentation/devicetree/bindings/leds/ir-leds/img-ir-rev1.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/img-ir-rev1.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/img-ir-rev1.txt
diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/leds/ir-leds/meson-ir.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/meson-ir.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/meson-ir.txt
diff --git a/Documentation/devicetree/bindings/media/nokia,n900-ir b/Documentation/devicetree/bindings/leds/ir-leds/nokia,n900-ir
similarity index 100%
rename from Documentation/devicetree/bindings/media/nokia,n900-ir
rename to Documentation/devicetree/bindings/leds/ir-leds/nokia,n900-ir
diff --git a/Documentation/devicetree/bindings/media/st-rc.txt b/Documentation/devicetree/bindings/leds/ir-leds/st-rc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/st-rc.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/st-rc.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/leds/ir-leds/sunxi-ir.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/sunxi-ir.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/sunxi-ir.txt
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Uwe Kleine-König @ 2016-11-10 13:57 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Martin Strbačka, Tomas Hlavacek, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..ae9fce9fed03 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -67,6 +67,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
--
2.10.2
--
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 v2 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-10 13:57 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Martin Strbačka, Tomas Hlavacek, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161110135721.13098-1-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
---
Compared to the (implict) v1, the following was changed:
- disable rtc
- change compatible to cznic,turris-omnia
The following components are working:
- WAN port
- eMMC
- UART0
- USB
- mSATA
Wireless fails to probe, didn't debug this up to now.
I already see the DSA devices (with an additional change not included here),
but sending and receiving doesn't work yet.
SFP is missing as I cannot test it. UART1 is untested, but I'd be
surprised if it didn't work.
IMHO it makes sense to add the current state and fix the remaining stuff
incrementally.
Best regards
Uwe
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 257 ++++++++++++++++++++++++++
2 files changed, 258 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..28e45d816120
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,257 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+ internal-regs {
+
+ /* USB part of the eSATA/USB 2.0 port */
+ usb@58000 {
+ status = "okay";
+ };
+
+ rtc@a3800 {
+ /*
+ * There are several errata for this device
+ * still unimplemented. Without some love it only reports
+ * 2016-12-19 22:00:24. So disable for now.
+ */
+ status = "disabled";
+ };
+
+ sata@a8000 {
+ status = "okay";
+ };
+
+ sdhci@d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3@f0000 {
+ status = "okay";
+ };
+
+ usb3@f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie@2,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+
+ pcie@3,0 {
+ /* Port 3, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux@70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+
+ /* STM32F0 at address 0x2a */
+ /* leds device at address 0x2b */
+
+ eeprom@54 {
+ /* holds configuration about RAM, evaluated by bootloader */
+ compatible = "at,24c64";
+ reg = <0x54>;
+ };
+ };
+
+ i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ /* ATSHA204A at address 0x64 */
+ };
+
+ i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ /* exposed on pin header */
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy@1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+
+ /* There is a Switch (MV88E7176) at address 0x10 */
+};
+
+&pinctrl {
+ spi0cs1_pins: spi0-pins-0cs1 {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+ status = "okay";
+
+ spi-nor@0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition@0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition@1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* @1 is on pin header */
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
--
2.10.2
--
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 v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Rob Herring @ 2016-11-10 14:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Neil Armstrong, Olof Johansson,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-amlogic
In-Reply-To: <14e563ae-36c5-4bf9-0d51-3b07830de3db@arm.com>
On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 01:22, Rob Herring wrote:
>>
>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>
>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> index d1882c4540d0..ebd03fc93135 100644
>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>> operations.
>>>
>>> Required properties:
>>>
>>> -- compatible : should be "arm,scpi"
>>> +- compatible : should be
>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>> above
>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>
>>
>> I'd prefer that we explicitly enumerate the old versions. Are there
>> many?
>>
>
> I understand your concern, but this legacy SCPI protocol was not
> officially released. It was just WIP which vendors picked up from very
> early releases. Since they are not numbered, it's hard to have specific
> compatibles with different versions until v1.0. That's one of the reason
> to retain platform specific compatible so that we can add any quirks
> based on them if needed.
>
> I will probably add these information in the commit log so that it's
> clear why we can't do version based compatible.
This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.
Rob
^ permalink raw reply
* Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"
From: Greg Kroah-Hartman @ 2016-11-10 14:14 UTC (permalink / raw)
To: Michael Ellerman
Cc: Linus Torvalds, Hans de Goede, Andrew Morton, Paul Burton,
Rob Herring, Frank Rowand, Thorsten Leemhuis, Tejun Heo,
devicetree, linux-kernel
In-Reply-To: <20161108070032.GB13866@kroah.com>
On Tue, Nov 08, 2016 at 08:00:32AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 08, 2016 at 11:46:35AM +1100, Michael Ellerman wrote:
> > Hans de Goede <hdegoede@redhat.com> writes:
> >
> > > This reverts commit 05fd007e4629 ("console: don't prefer first registered
> > > if DT specifies stdout-path").
> > >
> > > The reverted commit changes existing behavior on which many ARM boards
> > > rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> > > both a video output and a serial console. Depending on whether the user
> > > is using the device as a more regular computer; or as a headless device
> > > we need to have the console on either one or the other.
> > >
> > > Many users rely on the kernel behavior of the console being present on
> > > both outputs, before the reverted commit the console setup with no
> > > console= kernel arguments on an ARM board which sets stdout-path in dt
> > > would look like this:
> > >
> > > [root@localhost ~]# cat /proc/consoles
> > > ttyS0 -W- (EC p a) 4:64
> > > tty0 -WU (E p ) 4:1
> > >
> > > Where as after the reverted commit, it looks like this:
> > >
> > > [root@localhost ~]# cat /proc/consoles
> > > ttyS0 -W- (EC p a) 4:64
> > >
> > > This commit reverts commit 05fd007e4629 ("console: don't prefer first
> > > registered if DT specifies stdout-path") restoring the original behavior.
> > >
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >
> > This is also breaking various powerpc systems.
> >
> > Linus can you please merge this revert for 4.9 ?
>
> I'll queue it up with other tty changes for 4.9-final.
Oops, wait, it's going through Andrew's tree, nevermind...
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Andrew Lunn @ 2016-11-10 14:15 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jason Cooper, Gregory Clement, Sebastian Hesselbarth,
Martin Strba??ka, Tomas Hlavacek, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161110135721.13098-1-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
On Thu, Nov 10, 2016 at 02:57:20PM +0100, Uwe Kleine-König wrote:
> Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
Hi Uwe
It is normal to send vendor-prefixes patches directly to the device
tree maintainers as a separate patch. That avoids merge conflicts on
the file.
Andrew
--
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: [PATCHv3 2/4] misc: Add Altera Arria10 System Resource Control
From: Greg KH @ 2016-11-10 14:33 UTC (permalink / raw)
To: tthayer
Cc: lee.jones, robh+dt, mark.rutland, dinguyen, linux, arnd, davem,
geert, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1478097178-24341-3-git-send-email-tthayer@opensource.altera.com>
On Wed, Nov 02, 2016 at 09:32:56AM -0500, tthayer@opensource.altera.com wrote:
> From: Thor Thayer <tthayer@opensource.altera.com>
>
> This patch adds the Altera Arria10 control & monitoring
> functions to the Arria10 System Resource chip.
>
> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
> ---
> v2 Change compatible string and filename from -mon to -monitor
> Change CONFIG from module to builtin.
> Make wm_rst register writeable.
> v3 Remove unused ret variable.
> Shorten driver name (remove altr_).
> ---
> MAINTAINERS | 1 +
> drivers/misc/Kconfig | 7 ++
> drivers/misc/Makefile | 1 +
> drivers/misc/altera-a10sr-monitor.c | 175 ++++++++++++++++++++++++++++++++++++
> 4 files changed, 184 insertions(+)
> create mode 100644 drivers/misc/altera-a10sr-monitor.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b180821..baf2404 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -635,6 +635,7 @@ M: Thor Thayer <tthayer@opensource.altera.com>
> S: Maintained
> F: drivers/gpio/gpio-altera-a10sr.c
> F: drivers/mfd/altera-a10sr.c
> +F: drivers/misc/altera-a10sr-monitor.c
> F: include/linux/mfd/altera-a10sr.h
>
> ALTERA TRIPLE SPEED ETHERNET DRIVER
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 64971ba..f42d459 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -766,6 +766,13 @@ config PANEL_BOOT_MESSAGE
> An empty message will only clear the display at driver init time. Any other
> printf()-formatted message is valid with newline and escape codes.
>
> +config ALTERA_A10SR_MONITOR
> + bool "Altera Arria10 System Resource Monitor"
> + depends on MFD_ALTERA_A10SR
> + help
> + This enables the System Resource monitor driver for the Altera
> + Arria10 DevKit.
> +
> source "drivers/misc/c2port/Kconfig"
> source "drivers/misc/eeprom/Kconfig"
> source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 3198336..9f6e77a 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -43,6 +43,7 @@ obj-y += ti-st/
> obj-y += lis3lv02d/
> obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
> obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
> +obj-$(CONFIG_ALTERA_A10SR_MONITOR) += altera-a10sr-monitor.o
> obj-$(CONFIG_INTEL_MEI) += mei/
> obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
> obj-$(CONFIG_LATTICE_ECP3_CONFIG) += lattice-ecp3-config.o
> diff --git a/drivers/misc/altera-a10sr-monitor.c b/drivers/misc/altera-a10sr-monitor.c
> new file mode 100644
> index 0000000..66338e0
> --- /dev/null
> +++ b/drivers/misc/altera-a10sr-monitor.c
> @@ -0,0 +1,175 @@
> +/*
> + * Altera Arria10 DevKit System Resource Chip Monitor Driver
> + *
> + * Author: Thor Thayer <tthayer@opensource.altera.com>
> + *
> + * Copyright Intel Corporation (C) 2014-2016. All Rights Reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program. If not, see <http://www.gnu.org/licenses/>.
> + *
> + * Monitor driver for the Altera Arria10 MAX5 System Resource Chip
> + * Adapted from ics932s401.c
> + */
> +
> +#include <linux/err.h>
> +#include <linux/mfd/altera-a10sr.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +struct altr_a10sr_regs {
> + struct regmap *regmap;
> + struct attribute_group attr_grp;
> +};
> +
> +static ssize_t a10sr_show(struct device *dev,
> + struct device_attribute *devattr, char *buf);
> +static ssize_t a10sr_store(struct device *dev,
> + struct device_attribute *devattr, const char *buf,
> + size_t count);
> +
> +/* Define FS entries */
> +static DEVICE_ATTR(max5_version, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_led, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_button, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_button_irq, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_pg1, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_pg2, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_pg3, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_fmcab, 0444, a10sr_show, NULL);
> +static DEVICE_ATTR(max5_hps_resets, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_per_resets, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_sfpa, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_sfpb, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_i2c_master, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_wm_rst, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_wm_rst_key, 0644, a10sr_show, a10sr_store);
> +static DEVICE_ATTR(max5_pmbus, 0644, a10sr_show, a10sr_store);
Please add a Documentation/ABI file to describe all of thes new sysfs
files that you are saying will be present for all of time.
And do you really want userspace access like this to these values?
Shouldn't things like the led and button use the proper led and input
layers instead?
> +static int altr_a10sr_regs_probe(struct platform_device *pdev)
> +{
> + struct altr_a10sr_regs *a10regs;
> + struct altr_a10sr *a10sr = dev_get_drvdata(pdev->dev.parent);
> +
> + a10regs = devm_kzalloc(&pdev->dev, sizeof(*a10regs), GFP_KERNEL);
> + if (!a10regs)
> + return -ENOMEM;
> +
> + a10regs->regmap = a10sr->regmap;
> + a10regs->attr_grp = a10sr_attr_group;
> +
> + platform_set_drvdata(pdev, a10regs);
> +
> + return sysfs_create_group(&pdev->dev.kobj, &a10sr_attr_group);
You just raced userspace and lost :(
Please set the group file properly, and then the driver core should set
this up for you correctly.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-10 14:34 UTC (permalink / raw)
To: Rob Herring
Cc: Sudeep Holla, Neil Armstrong, Olof Johansson,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CAL_JsqLW4JZHb0ncVUEefnKySA231EDgvCkY3xPdaJGf=uMJYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/11/16 14:12, Rob Herring wrote:
> On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org> wrote:
>>
>>
>> On 10/11/16 01:22, Rob Herring wrote:
>>>
>>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>>
>>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>>
>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> index d1882c4540d0..ebd03fc93135 100644
>>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>>> operations.
>>>>
>>>> Required properties:
>>>>
>>>> -- compatible : should be "arm,scpi"
>>>> +- compatible : should be
>>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>>> above
>>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>>
>>>
>>> I'd prefer that we explicitly enumerate the old versions. Are there
>>> many?
>>>
>>
>> I understand your concern, but this legacy SCPI protocol was not
>> officially released. It was just WIP which vendors picked up from very
>> early releases. Since they are not numbered, it's hard to have specific
>> compatibles with different versions until v1.0. That's one of the reason
>> to retain platform specific compatible so that we can add any quirks
>> based on them if needed.
>>
>> I will probably add these information in the commit log so that it's
>> clear why we can't do version based compatible.
>
> This is exactly my point. By enumerate, I meant having platform
> specific compatibles. Having "arm,legacy-scpi" is pointless because
> who knows what version they followed and they may all be different.
>
OK, but IIUC Olof's concern wanted a generic one along with the platform
specific compatible which kind of makes sense as so far we have seen
some commonality between Amlogic and Rockchip.
E.g. Amlogic follows most of the legacy protocol though it deviates in
couple of things which we can handle with platform specific compatible
(in the following patch in the series). When another user(Rockchip ?)
make use of this legacy protocol, we can start using those platform
specific compatible for deviations only.
Is that not acceptable ?
--
Regards,
Sudeep
--
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
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Jesper Nilsson @ 2016-11-10 15:09 UTC (permalink / raw)
Cc: Lars Persson, Niklas Cassel, Rob Herring, Mark Rutland,
Russell King, open list:ARM/ARTPEC MACHINE SUPPORT,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM PORT, open list
Hi!
Please pull the below signed tag for a trio of minor changes
adding PCIe for the ARM ARTPEC SoC.
Thanks!
/Jesper
The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git tags/artpec-for-4.10
for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
----------------------------------------------------------------
ARTPEC changes for 4.10
----------------------------------------------------------------
Niklas Cassel (3):
ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
ARM: ARTPEC-6: add pcie related options
ARM: dts: artpec: add pcie support
arch/arm/boot/dts/artpec6-devboard.dts | 4 ++++
arch/arm/boot/dts/artpec6.dtsi | 29 ++++++++++++++++++++++++++++-
arch/arm/mach-artpec/Kconfig | 3 +++
3 files changed, 35 insertions(+), 1 deletion(-)
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-10 15:36 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel@lists.infradead.org
Cc: Yuanzhichang, mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org,
kantyzc@163.com, linux-serial@vger.kernel.org, catalin.marinas@
In-Reply-To: <17821285.aIcTyCGn5n@wuerfel>
Hi Arnd
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 10 November 2016 09:12
> To: linux-arm-kernel@lists.infradead.org
> Cc: Yuanzhichang; mark.rutland@arm.com; devicetree@vger.kernel.org;
> lorenzo.pieralisi@arm.com; Gabriele Paoloni; minyard@acm.org; linux-
> pci@vger.kernel.org; benh@kernel.crashing.org; John Garry;
> will.deacon@arm.com; linux-kernel@vger.kernel.org; xuwei (O); Linuxarm;
> zourongrong@gmail.com; robh+dt@kernel.org; kantyzc@163.com; linux-
> serial@vger.kernel.org; catalin.marinas@arm.com; olof@lixom.net;
> liviu.dudau@arm.com; bhelgaas@google.com; zhichang.yuan02@gmail.com
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
> > On 2016/11/10 5:34, Arnd Bergmann wrote:
> > > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni
> wrote:
> > >>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > >>>> + /*
> > >>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
> > >>> indirectIO.
> > >>>> + * It will separate indirectIO range from pci host
> bridge to
> > >>>> + * avoid the possible PIO conflict.
> > >>>> + * Set the indirectIO range directly here.
> > >>>> + */
> > >>>> + lpcdev->io_ops.start = 0;
> > >>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > >>>> + lpcdev->io_ops.devpara = lpcdev;
> > >>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > >>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > >>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > >>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> > >>>
> > >>> I have to look at patch 2 in more detail again, after missing a
> few
> > >>> review
> > >>> rounds. I'm still a bit skeptical about hardcoding a logical I/O
> port
> > >>> range here, and would hope that we can just go through the same
> > >>> assignment of logical port ranges that we have for PCI buses,
> > >>> decoupling
> > >>> the bus addresses from the linux-internal ones.
> > >>
> > >> The point here is that we want to avoid any conflict/overlap
> between
> > >> the LPC I/O space and the PCI I/O space. With the assignment above
> > >> we make sure that LPC never interfere with PCI I/O space.
> > >
> > > But we already abstract the PCI I/O space using dynamic
> registration.
> > > There is no need to hardcode the logical address for ISA, though
> > > I think we can hardcode the bus address to start at zero here.
> >
> > Do you means that we can pick up the maximal I/O address from all
> children's
> > device resources??
>
> The driver should not look at the resources of its children, just
> register a range of addresses dynamically, as I suggested in an
> earlier review.
Where should we get the range from? For LPC we know that it is going
Work on anything that is not used by PCI I/O space, and this is
why we use [0, PCIBIOS_MIN_IO]
>
>
> Your current version has
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr, value, sizeof(type)); \
>
> Instead, just subtract the start of the range from the logical
> port number to transform it back into a bus-local port number:
These accessors do not operate on IO tokens:
If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
addr is not going to be an I/O token; in fact patch 2/3 imposes that
the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to PCIBIOS_MIN_IO
we have free physical addresses that the accessors can operate on.
Thanks
Gab
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr - arm64_extio_ops->start, value,
> sizeof(type)); \
>
> We know that the ISA/LPC bus can only have up to 65536 ports,
> so you can register all of those, or possibly limit it further to
> 1024 or 4096 ports, whichever matches the bus implementation.
>
> Arnd
^ permalink raw reply
* [PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices
From: Olimpiu Dejeu @ 2016-11-10 15:44 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, Olimpiu Dejeu
Resubmition of arcxcnn backlight driver addressing the naming convention
concerns raised by Rob H.
Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
---
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/arcxcnn_bl.c | 541 +++++++++++++++++++++++++++++++++++
include/linux/i2c/arcxcnn.h | 67 +++++
4 files changed, 616 insertions(+)
create mode 100644 drivers/video/backlight/arcxcnn_bl.c
create mode 100644 include/linux/i2c/arcxcnn.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..4e1d2ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -460,6 +460,13 @@ config BACKLIGHT_BD6107
help
If you have a Rohm BD6107 say Y to enable the backlight driver.
+config BACKLIGHT_ARCXCNN
+ tristate "Backlight driver for the Arctic Sands ARCxCnnnn family"
+ depends on I2C
+ help
+ If you have an ARCxCnnnn family backlight say Y to enable
+ the backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..8905129 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
+obj-$(CONFIG_BACKLIGHT_ARCXCNN) += arcxcnn_bl.o
diff --git a/drivers/video/backlight/arcxcnn_bl.c b/drivers/video/backlight/arcxcnn_bl.c
new file mode 100644
index 0000000..1dad680
--- /dev/null
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -0,0 +1,541 @@
+/*
+ * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/pwm.h>
+#include <linux/regulator/consumer.h>
+
+#include "linux/i2c/arcxcnn.h"
+
+#define ARCXCNN_CMD (0x00) /* Command Register */
+#define ARCXCNN_CMD_STDBY (0x80) /* I2C Standby */
+#define ARCXCNN_CMD_RESET (0x40) /* Reset */
+#define ARCXCNN_CMD_BOOST (0x10) /* Boost */
+#define ARCXCNN_CMD_OVP_MASK (0x0C) /* --- Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_XXV (0x0C) /* <rsvrd> Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_20V (0x08) /* 20v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_24V (0x04) /* 24v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_31V (0x00) /* 31.4v Over Voltage Threshold */
+#define ARCXCNN_CMD_EXT_COMP (0x01) /* part (0) or full (1) external comp */
+
+#define ARCXCNN_CONFIG (0x01) /* Configuration */
+#define ARCXCNN_STATUS1 (0x02) /* Status 1 */
+#define ARCXCNN_STATUS2 (0x03) /* Status 2 */
+#define ARCXCNN_FADECTRL (0x04) /* Fading Control */
+#define ARCXCNN_ILED_CONFIG (0x05) /* ILED Configuration */
+
+#define ARCXCNN_LEDEN (0x06) /* LED Enable Register */
+#define ARCXCNN_LEDEN_ISETEXT (0x80) /* Full-scale current set externally */
+#define ARCXCNN_LEDEN_MASK (0x3F) /* LED string enables */
+#define ARCXCNN_LEDEN_LED1 (0x01)
+#define ARCXCNN_LEDEN_LED2 (0x02)
+#define ARCXCNN_LEDEN_LED3 (0x04)
+#define ARCXCNN_LEDEN_LED4 (0x08)
+#define ARCXCNN_LEDEN_LED5 (0x10)
+#define ARCXCNN_LEDEN_LED6 (0x20)
+
+#define ARCXCNN_WLED_ISET_LSB (0x07) /* LED ISET LSB (in upper nibble) */
+#define ARCXCNN_WLED_ISET_MSB (0x08) /* LED ISET MSB (8 bits) */
+
+#define ARCXCNN_DIMFREQ (0x09)
+#define ARCXCNN_COMP_CONFIG (0x0A)
+#define ARCXCNN_FILT_CONFIG (0x0B)
+#define ARCXCNN_IMAXTUNE (0x0C)
+
+#define DEFAULT_BL_NAME "arctic_bl"
+#define MAX_BRIGHTNESS 4095
+
+static int s_no_reset_on_remove;
+module_param_named(noreset, s_no_reset_on_remove, int, 0644);
+MODULE_PARM_DESC(noreset, "No reset on module removal");
+
+static int s_ibright = 60;
+module_param_named(ibright, s_ibright, int, 0644);
+MODULE_PARM_DESC(ibright, "Initial brightness (when no plat data)");
+
+static int s_iledstr = 0x3F;
+module_param_named(iledstr, s_iledstr, int, 0644);
+MODULE_PARM_DESC(iledstr, "Initial LED String (when no plat data)");
+
+static int s_retries = 2; /* 1 == only one try */
+module_param_named(retries, s_retries, int, 0644);
+MODULE_PARM_DESC(retries, "I2C retries attempted");
+
+enum arcxcnn_brightness_ctrl_mode {
+ PWM_BASED = 1,
+ REGISTER_BASED,
+};
+
+struct arcxcnn;
+
+struct arcxcnn {
+ char chipname[64];
+ enum arcxcnn_chip_id chip_id;
+ enum arcxcnn_brightness_ctrl_mode mode;
+ struct i2c_client *client;
+ struct backlight_device *bl;
+ struct device *dev;
+ struct arcxcnn_platform_data *pdata;
+ struct pwm_device *pwm;
+ struct regulator *supply; /* regulator for VDD input */
+};
+
+static int arcxcnn_write_byte(struct arcxcnn *lp, u8 reg, u8 data)
+{
+ s32 ret = -1;
+ int att;
+
+ for (att = 0; att < s_retries; att++) {
+ ret = i2c_smbus_write_byte_data(lp->client, reg, data);
+ if (ret >= 0)
+ return 0;
+ }
+ return ret;
+}
+
+static u8 arcxcnn_read_byte(struct arcxcnn *lp, u8 reg)
+{
+ int val;
+ int att;
+
+ for (att = 0; att < s_retries; att++) {
+ val = i2c_smbus_read_byte_data(lp->client, reg);
+ if (val >= 0)
+ return (u8)val;
+ }
+ return 0;
+}
+
+static int arcxcnn_update_bit(struct arcxcnn *lp, u8 reg, u8 mask, u8 data)
+{
+ int ret, att;
+ u8 tmp;
+
+ for (att = 0, ret = -1; att < s_retries; att++) {
+ ret = i2c_smbus_read_byte_data(lp->client, reg);
+ if (ret >= 0)
+ break;
+ }
+ if (ret < 0) {
+ dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
+ return ret;
+ }
+
+ tmp = (u8)ret;
+ tmp &= ~mask;
+ tmp |= data & mask;
+
+ return arcxcnn_write_byte(lp, reg, tmp);
+}
+
+static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
+{
+ int ret;
+ u8 val;
+
+ val = (brightness & 0xF) << 4;
+ ret = arcxcnn_write_byte(lp, ARCXCNN_WLED_ISET_LSB, val);
+ if (ret < 0)
+ return ret;
+ val = (brightness >> 4);
+ ret = arcxcnn_write_byte(lp, ARCXCNN_WLED_ISET_MSB, val);
+ return ret;
+}
+
+static int arcxcnn_bl_update_status(struct backlight_device *bl)
+{
+ struct arcxcnn *lp = bl_get_data(bl);
+ u32 brightness = bl->props.brightness;
+
+ if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ brightness = 0;
+
+ /* set brightness */
+ if (lp->mode == PWM_BASED)
+ ; /* via pwm */
+ else if (lp->mode == REGISTER_BASED)
+ arcxcnn_set_brightness(lp, brightness);
+
+ /* set power-on/off/save modes */
+ if (bl->props.power == 0)
+ /* take out of standby */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY, 0);
+ else
+ /* 1-3 == power save, 4 = off
+ * place in low-power standby mode
+ */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD,
+ ARCXCNN_CMD_STDBY, ARCXCNN_CMD_STDBY);
+ return 0;
+}
+
+static const struct backlight_ops arcxcnn_bl_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = arcxcnn_bl_update_status,
+};
+
+static int arcxcnn_backlight_register(struct arcxcnn *lp)
+{
+ struct backlight_device *bl;
+ struct backlight_properties props;
+ struct arcxcnn_platform_data *pdata = lp->pdata;
+ const char *name = pdata->name ? : DEFAULT_BL_NAME;
+
+ memset(&props, 0, sizeof(props));
+ props.type = BACKLIGHT_PLATFORM;
+ props.max_brightness = MAX_BRIGHTNESS;
+
+ if (pdata->initial_brightness > props.max_brightness)
+ pdata->initial_brightness = props.max_brightness;
+
+ props.brightness = pdata->initial_brightness;
+
+ bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
+ &arcxcnn_bl_ops, &props);
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
+
+ lp->bl = bl;
+
+ return 0;
+}
+
+static ssize_t arcxcnn_get_chip_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", lp->chipname);
+}
+
+static ssize_t arcxcnn_get_led_str(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%02X\n", lp->pdata->led_str);
+}
+
+static ssize_t arcxcnn_set_led_str(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+ unsigned long ledstr;
+
+ if (kstrtoul(buf, 0, &ledstr))
+ return 0;
+
+ if (ledstr != lp->pdata->led_str) {
+ /* don't allow 0 for ledstr, use power to turn all off */
+ if (ledstr == 0)
+ return 0;
+ lp->pdata->led_str = ledstr & 0x3F;
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
+ }
+ return len;
+}
+
+static ssize_t arcxcnn_get_bl_ctl_mode(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+ char *strmode = NULL;
+
+ if (lp->mode == PWM_BASED)
+ strmode = "pwm based";
+ else if (lp->mode == REGISTER_BASED)
+ strmode = "register based";
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", strmode);
+}
+
+static DEVICE_ATTR(chip_id, 0444, arcxcnn_get_chip_id, NULL);
+static DEVICE_ATTR(led_str, 0664, arcxcnn_get_led_str, arcxcnn_set_led_str);
+static DEVICE_ATTR(bl_ctl_mode, 0444, arcxcnn_get_bl_ctl_mode, NULL);
+
+static struct attribute *arcxcnn_attributes[] = {
+ &dev_attr_chip_id.attr,
+ &dev_attr_led_str.attr,
+ &dev_attr_bl_ctl_mode.attr,
+ NULL,
+};
+
+static const struct attribute_group arcxcnn_attr_group = {
+ .attrs = arcxcnn_attributes,
+};
+
+#ifdef CONFIG_OF
+static int arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ struct device *dev = lp->dev;
+ struct device_node *node = dev->of_node;
+ u32 prog_val, num_entry, sources[6];
+ int ret;
+
+ if (!node) {
+ dev_err(dev, "no platform data.\n");
+ return -EINVAL;
+ }
+ lp->pdata->led_config_0_set = false;
+ lp->pdata->led_config_1_set = false;
+ lp->pdata->dim_freq_set = false;
+ lp->pdata->comp_config_set = false;
+ lp->pdata->filter_config_set = false;
+ lp->pdata->trim_config_set = false;
+
+ ret = of_property_read_string(node, "label", &lp->pdata->name);
+ if (ret < 0)
+ lp->pdata->name = NULL;
+
+ ret = of_property_read_u32(node, "default-brightness", &prog_val);
+ if (ret < 0)
+ prog_val = s_ibright;
+ lp->pdata->initial_brightness = prog_val;
+ if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
+ lp->pdata->initial_brightness = MAX_BRIGHTNESS;
+
+ ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+ if (ret == 0) {
+ lp->pdata->led_config_0 = (u8)prog_val;
+ lp->pdata->led_config_0_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
+ if (ret == 0) {
+ lp->pdata->led_config_1 = (u8)prog_val;
+ lp->pdata->led_config_1_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
+ if (ret == 0) {
+ lp->pdata->dim_freq = (u8)prog_val;
+ lp->pdata->dim_freq_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->comp_config = (u8)prog_val;
+ lp->pdata->comp_config_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->filter_config = (u8)prog_val;
+ lp->pdata->filter_config_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->trim_config = (u8)prog_val;
+ lp->pdata->trim_config_set = true;
+ }
+ ret = of_property_count_u32_elems(node, "led-sources");
+ if (ret < 0)
+ lp->pdata->led_str = 0x3F;
+ else {
+ num_entry = ret;
+ if (num_entry > 6)
+ num_entry = 6;
+
+ ret = of_property_read_u32_array(node, "led-sources", sources,
+ num_entry);
+ if (ret < 0) {
+ dev_err(dev, "led-sources node is invalid.\n");
+ return -EINVAL;
+ }
+
+ lp->pdata->led_str = 0;
+ while (num_entry > 0)
+ lp->pdata->led_str |= (1 << sources[--num_entry]);
+ }
+ return 0;
+}
+#else
+static int arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ return -EINVAL;
+}
+#endif
+
+static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
+{
+ struct arcxcnn *lp;
+ int ret;
+ u8 regval;
+ u16 chipid;
+
+ if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -EIO;
+
+ lp = devm_kzalloc(&cl->dev, sizeof(*lp), GFP_KERNEL);
+ if (!lp)
+ return -ENOMEM;
+
+ lp->client = cl;
+ lp->dev = &cl->dev;
+ lp->chip_id = id->driver_data;
+ lp->pdata = dev_get_platdata(&cl->dev);
+
+ if (!lp->pdata) {
+ lp->pdata = devm_kzalloc(lp->dev,
+ sizeof(*lp->pdata), GFP_KERNEL);
+ if (!lp->pdata)
+ return -ENOMEM;
+
+ /* no platform data, parse the device-tree for info. if there
+ * is no device tree entry, we are being told we exist because
+ * user-land said so, so make up the info we need
+ */
+ ret = arcxcnn_parse_dt(lp);
+ if (ret < 0) {
+ /* no device tree, use defaults based on module params
+ */
+ lp->pdata->led_config_0_set = false;
+ lp->pdata->led_config_1_set = false;
+ lp->pdata->dim_freq_set = false;
+ lp->pdata->comp_config_set = false;
+ lp->pdata->filter_config_set = false;
+ lp->pdata->trim_config_set = false;
+
+ lp->pdata->name = NULL;
+ lp->pdata->initial_brightness = s_ibright;
+ lp->pdata->led_str = s_iledstr;
+ }
+ }
+
+ if (lp->pdata->dim_freq_set)
+ lp->mode = PWM_BASED;
+ else
+ lp->mode = REGISTER_BASED;
+
+ i2c_set_clientdata(cl, lp);
+
+ /* read device ID */
+ regval = arcxcnn_read_byte(lp, 0x1E);
+ chipid = regval;
+ chipid <<= 8;
+ regval = arcxcnn_read_byte(lp, 0x1F);
+ chipid |= regval;
+
+ /* make sure it belongs to this driver
+ * TODO - handle specific ids
+ */
+ if (chipid != 0x02A5) {
+ #if 1
+ dev_info(&cl->dev, "Chip Id is %04X\n", chipid);
+ #else
+ dev_err(&cl->dev, "%04X is not ARC2C\n", chipid);
+ return -ENODEV;
+ #endif
+ }
+ /* reset the device */
+ arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+
+ /* set initial brightness */
+ arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
+
+ /* if fadectrl set in DT, set the value directly, else leave default */
+ if (lp->pdata->led_config_0_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FADECTRL,
+ lp->pdata->led_config_0);
+
+ /* if iled config set in DT, set the value, else internal mode */
+ if (lp->pdata->led_config_1_set)
+ arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG,
+ lp->pdata->led_config_1);
+ else
+ arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG, 0x57);
+
+ /* other misc DT settings */
+ if (lp->pdata->dim_freq_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FADECTRL, lp->pdata->dim_freq);
+ if (lp->pdata->comp_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_COMP_CONFIG,
+ lp->pdata->comp_config);
+ if (lp->pdata->filter_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FILT_CONFIG,
+ lp->pdata->filter_config);
+ if (lp->pdata->trim_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_IMAXTUNE,
+ lp->pdata->trim_config);
+
+ /* set initial LED Strings */
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
+
+ snprintf(lp->chipname, sizeof(lp->chipname),
+ "%s-%04X", id->name, chipid);
+
+ ret = arcxcnn_backlight_register(lp);
+ if (ret) {
+ dev_err(lp->dev,
+ "failed to register backlight. err: %d\n", ret);
+ return ret;
+ }
+
+ ret = sysfs_create_group(&lp->dev->kobj, &arcxcnn_attr_group);
+ if (ret) {
+ dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
+ return ret;
+ }
+
+ backlight_update_status(lp->bl);
+ return 0;
+}
+
+static int arcxcnn_remove(struct i2c_client *cl)
+{
+ struct arcxcnn *lp = i2c_get_clientdata(cl);
+
+ if (!s_no_reset_on_remove) {
+ /* disable all strings */
+ arcxcnn_write_byte(lp, ARCXCNN_LEDEN, 0x00);
+ /* reset the device */
+ arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+ }
+ lp->bl->props.brightness = 0;
+ backlight_update_status(lp->bl);
+ if (lp->supply)
+ regulator_disable(lp->supply);
+ sysfs_remove_group(&lp->dev->kobj, &arcxcnn_attr_group);
+
+ return 0;
+}
+
+static const struct of_device_id arcxcnn_dt_ids[] = {
+ { .compatible = "arc,arc2c0608" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
+
+/* Note that the device/chip ID is not fixed in silicon so
+ * auto-probing of these devices on the bus is most likely
+ * not possible, use device tree to set i2c bus address
+ */
+static const struct i2c_device_id arcxcnn_ids[] = {
+ {"arc2c0608", ARC2C0608},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);
+
+static struct i2c_driver arcxcnn_driver = {
+ .driver = {
+ .name = "arcxcnn_bl",
+ .of_match_table = of_match_ptr(arcxcnn_dt_ids),
+ },
+ .probe = arcxcnn_probe,
+ .remove = arcxcnn_remove,
+ .id_table = arcxcnn_ids,
+};
+
+module_i2c_driver(arcxcnn_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Brian Dodge <bdodge09-1ViLX0X+lBJBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("ARCXCNN Backlight driver");
diff --git a/include/linux/i2c/arcxcnn.h b/include/linux/i2c/arcxcnn.h
new file mode 100644
index 0000000..1c681dd
--- /dev/null
+++ b/include/linux/i2c/arcxcnn.h
@@ -0,0 +1,67 @@
+/*
+ * Backlight driver for ArcticSand ARC2C0608 Backlight Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef _ARCXCNN_H
+#define _ARCXCNN_H
+
+enum arcxcnn_chip_id {
+ ARC2C0608
+};
+
+enum arcxcnn_brightness_source {
+ ARCXCNN_PWM_ONLY,
+ ARCXCNN_I2C_ONLY = 2,
+};
+
+#define ARCXCNN_MAX_PROGENTRIES 48 /* max a/v pairs for custom */
+
+/**
+ * struct arcxcnn_platform_data
+ * @name : Backlight driver name. If it is not defined, default name is set.
+ * @initial_brightness : initial value of backlight brightness
+ * @led_str : initial LED string enables, upper bit is global on/off
+ * @led_config_0 : fading speed (period between intensity steps)
+ * @led_config_1 : misc settings, see datasheet
+ * @dim_freq : pwm dimming frequency if in pwm mode
+ * @comp_config : misc config, see datasheet
+ * @filter_config: RC/PWM filter config, see datasheet
+ * @trim_config : full scale current trim, see datasheet
+ * @led_config_0_set : the value in led_config_0 is valid
+ * @led_config_1_set : the value in led_config_1 is valid
+ * @dim_freq_set : the value in dim_freq is valid
+ * @comp_config_set : the value in comp_config is valid
+ * @filter_config_set : the value in filter_config is valid
+ * @trim_config_set : the value in trim_config is valid
+ *
+ * the _set flags are used to indicate that the value was explicitly set
+ * in the device tree or platform data. settings not set are left as default
+ * power-on default values of the chip except for led_str and led_config_1
+ * which are set by the driver (led_str is specified indirectly in the
+ * device tree via "led-sources")
+ */
+struct arcxcnn_platform_data {
+ const char *name;
+ u16 initial_brightness;
+ u8 led_str;
+
+ u8 led_config_0;
+ u8 led_config_1;
+ u8 dim_freq;
+ u8 comp_config;
+ u8 filter_config;
+ u8 trim_config;
+
+ bool led_config_0_set;
+ bool led_config_1_set;
+ bool dim_freq_set;
+ bool comp_config_set;
+ bool filter_config_set;
+ bool trim_config_set;
+};
+
+#endif
--
2.7.4
--
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 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices
From: Olimpiu Dejeu @ 2016-11-10 15:44 UTC (permalink / raw)
To: robh
Cc: lee.jones, linux-kernel, linux-fbdev, devicetree, jingoohan1,
Olimpiu Dejeu
Resubmition of arcxcnn backlight driver addressing the naming convention
concerns raised by Rob H. Note that all the device tree properties are
determined by the board design or IC EPROM settings and are not intended
to be user adjustable.
Signed-off-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
---
.../bindings/leds/backlight/arcxcnn_bl.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
new file mode 100644
index 0000000..a7b6ff2
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -0,0 +1,33 @@
+Binding for ArcticSand arc2c0608 LED driver
+
+Required properties:
+- compatible: should be "arc,arc2c0608"
+- reg: slave address
+
+Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+- label: The name of the backlight device
+ See Documentation/devicetree/bindings/leds/common.txt
+- led-sources: List of enabled channels from 0 to 5.
+ See Documentation/devicetree/bindings/leds/common.txt
+
+- arc,led-config-0: setting for register ILED_CONFIG_0
+- arc,led-config-1: setting for register ILED_CONFIG_1
+- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arc,comp-config: setting for register CONFIG_COMP
+- arc,filter-config: setting for register FILTER_CONFIG
+- arc,trim-config: setting for register IMAXTUNE
+
+Note: Optional properties not specified will default to values in IC EPROM
+
+Example:
+
+arc2c0608@30 {
+ compatible = "arc,arc2c0608";
+ reg = <0x30>;
+ default-brightness = <500>;
+ label = "lcd-backlight";
+ linux,default-trigger = "backlight";
+ led-sources = <0 1 2 5>;
+};
+
--
2.7.4
^ permalink raw reply related
* RE: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: Gabriele Paoloni @ 2016-11-10 16:06 UTC (permalink / raw)
To: liviu.dudau-5wv7dgnIgG8@public.gmane.org
Cc: Yuanzhichang, catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linuxarm,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"minyard-HInyCGIudOg@public.gmane.org" <mi>
In-Reply-To: <20161109165044.GE10219-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
Hi Liviu
> -----Original Message-----
> From: liviu.dudau@arm.com [mailto:liviu.dudau@arm.com]
> Sent: 09 November 2016 16:51
> To: Gabriele Paoloni
> Cc: Yuanzhichang; catalin.marinas@arm.com; will.deacon@arm.com;
> robh+dt@kernel.org; bhelgaas@google.com; mark.rutland@arm.com;
> olof@lixom.net; arnd@arndb.de; linux-arm-kernel@lists.infradead.org;
> lorenzo.pieralisi@arm.com; linux-kernel@vger.kernel.org; Linuxarm;
> devicetree@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> serial@vger.kernel.org; minyard@acm.org; benh@kernel.crashing.org;
> zourongrong@gmail.com; John Garry; zhichang.yuan02@gmail.com;
> kantyzc@163.com; xuwei (O)
> Subject: Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for
> special ISA
>
> On Wed, Nov 09, 2016 at 04:16:17PM +0000, Gabriele Paoloni wrote:
> > Hi Liviu
> >
> > Thanks for reviewing
> >
>
> [removed some irrelevant part of discussion, avoid crazy formatting]
>
> > > > +/**
> > > > + * addr_is_indirect_io - check whether the input taddr is for
> > > indirectIO.
> > > > + * @taddr: the io address to be checked.
> > > > + *
> > > > + * Returns 1 when taddr is in the range; otherwise return 0.
> > > > + */
> > > > +int addr_is_indirect_io(u64 taddr)
> > > > +{
> > > > + if (arm64_extio_ops->start > taddr || arm64_extio_ops->end
> <
> > > taddr)
> > >
> > > start >= taddr ?
> >
> > Nope... if (taddr < arm64_extio_ops->start || taddr >
> arm64_extio_ops->end)
> > then taddr is outside the range [start; end] and will return 0;
> otherwise
> > it will return 1...
>
> Oops, sorry, did not pay attention to the returned value. The check is
> correct as it is, no need to change then.
>
> >
> > >
> > > > + return 0;
> > > > +
> > > > + return 1;
> > > > +}
> > > >
> > > > BUILD_EXTIO(b, u8)
> > > >
> > > > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > > > index 02b2903..cc2a05d 100644
> > > > --- a/drivers/of/address.c
> > > > +++ b/drivers/of/address.c
> > > > @@ -479,6 +479,50 @@ static int of_empty_ranges_quirk(struct
> > > device_node *np)
> > > > return false;
> > > > }
> > > >
> > > > +
> > > > +/*
> > > > + * of_isa_indirect_io - get the IO address from some isa reg
> > > property value.
> > > > + * For some isa/lpc devices, no ranges property in ancestor
> node.
> > > > + * The device addresses are described directly in their regs
> > > property.
> > > > + * This fixup function will be called to get the IO address of
> > > isa/lpc
> > > > + * devices when the normal of_translation failed.
> > > > + *
> > > > + * @parent: points to the parent dts node;
> > > > + * @bus: points to the of_bus which can be used to parse
> > > address;
> > > > + * @addr: the address from reg property;
> > > > + * @na: the address cell counter of @addr;
> > > > + * @presult: store the address paresed from @addr;
> > > > + *
> > > > + * return 1 when successfully get the I/O address;
> > > > + * 0 will return for some failures.
> > >
> > > Bah, you are returning a signed int, why 0 for failure? Return a
> > > negative value with
> > > error codes. Otherwise change the return value into a bool.
> >
> > Yes we'll move to bool
> >
> > >
> > > > + */
> > > > +static int of_get_isa_indirect_io(struct device_node *parent,
> > > > + struct of_bus *bus, __be32 *addr,
> > > > + int na, u64 *presult)
> > > > +{
> > > > + unsigned int flags;
> > > > + unsigned int rlen;
> > > > +
> > > > + /* whether support indirectIO */
> > > > + if (!indirect_io_enabled())
> > > > + return 0;
> > > > +
> > > > + if (!of_bus_isa_match(parent))
> > > > + return 0;
> > > > +
> > > > + flags = bus->get_flags(addr);
> > > > + if (!(flags & IORESOURCE_IO))
> > > > + return 0;
> > > > +
> > > > + /* there is ranges property, apply the normal translation
> > > directly. */
> > >
> > > s/there is ranges/if we have a 'ranges'/
> >
> > Thanks for spotting this
> >
> > >
> > > > + if (of_get_property(parent, "ranges", &rlen))
> > > > + return 0;
> > > > +
> > > > + *presult = of_read_number(addr + 1, na - 1);
> > > > + /* this fixup is only valid for specific I/O range. */
> > > > + return addr_is_indirect_io(*presult);
> > > > +}
> > > > +
> > > > static int of_translate_one(struct device_node *parent, struct
> > > of_bus *bus,
> > > > struct of_bus *pbus, __be32 *addr,
> > > > int na, int ns, int pna, const char *rprop)
> > > > @@ -595,6 +639,15 @@ static u64 __of_translate_address(struct
> > > device_node *dev,
> > > > result = of_read_number(addr, na);
> > > > break;
> > > > }
> > > > + /*
> > > > + * For indirectIO device which has no ranges
> property, get
> > > > + * the address from reg directly.
> > > > + */
> > > > + if (of_get_isa_indirect_io(dev, bus, addr, na,
> &result)) {
> > > > + pr_debug("isa indirectIO matched(%s)..addr =
> > > 0x%llx\n",
> > > > + of_node_full_name(dev), result);
> > > > + break;
> > > > + }
> > > >
> > > > /* Get new parent bus and counts */
> > > > pbus = of_match_bus(parent);
> > > > @@ -688,8 +741,9 @@ static int __of_address_to_resource(struct
> > > device_node *dev,
> > > > if (taddr == OF_BAD_ADDR)
> > > > return -EINVAL;
> > > > memset(r, 0, sizeof(struct resource));
> > > > - if (flags & IORESOURCE_IO) {
> > > > + if (flags & IORESOURCE_IO && taddr >= PCIBIOS_MIN_IO) {
> > > > unsigned long port;
> > > > +
> > > > port = pci_address_to_pio(taddr);
> > > > if (port == (unsigned long)-1)
> > > > return -EINVAL;
> > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > > index ba34907..1a08511 100644
> > > > --- a/drivers/pci/pci.c
> > > > +++ b/drivers/pci/pci.c
> > > > @@ -3263,7 +3263,7 @@ int __weak
> pci_register_io_range(phys_addr_t
> > > addr, resource_size_t size)
> > > >
> > > > #ifdef PCI_IOBASE
> > > > struct io_range *range;
> > > > - resource_size_t allocated_size = 0;
> > > > + resource_size_t allocated_size = PCIBIOS_MIN_IO;
> > > >
> > > > /* check if the range hasn't been previously recorded */
> > > > spin_lock(&io_range_lock);
> > > > @@ -3312,7 +3312,7 @@ phys_addr_t pci_pio_to_address(unsigned
> long
> > > pio)
> > > >
> > > > #ifdef PCI_IOBASE
> > > > struct io_range *range;
> > > > - resource_size_t allocated_size = 0;
> > > > + resource_size_t allocated_size = PCIBIOS_MIN_IO;
> > >
> > > Have you checked that pci_pio_to_address still returns valid values
> > > after this? I know that
> > > you are trying to take into account PCIBIOS_MIN_IO limit when
> > > allocating reserving the IO ranges,
> > > but the values added in the io_range_list are still starting from
> zero,
> > > no from PCIBIOS_MIN_IO,
> >
> > I think you're wrong here as in pci_address_to_pio we have:
> > + resource_size_t offset = PCIBIOS_MIN_IO;
> >
> > This should be enough to guarantee that the PIOs start at
> > PCIBIOS_MIN_IO...right?
>
> I don't think you can guarantee that the pio value that gets passed
> into
> pci_pio_to_address() always comes from a previously returned value by
> pci_address_to_pio(). Maybe you can add a check in pci_pio_to_address()
Maybe I am missing something...could you make an exampleof a case
where an IO toke doesn’t come from pci_address_to_pio() ?
Thanks
Gab
>
> if (pio < PCIBIOS_MIN_IO)
> return address;
>
> to avoid adding more checks in the list_for_each_entry() loop.
>
> Best regards,
> Liviu
>
> >
> >
> > > so the calculation of the address in this function could return
> > > negative values casted to pci_addr_t.
> > >
> > > Maybe you want to adjust the range->start value in
> > > pci_register_io_range() as well to have it
> > > offset by PCIBIOS_MIN_IO as well.
> > >
> > > Best regards,
> > > Liviu
> > >
> > > >
> > > > if (pio > IO_SPACE_LIMIT)
> > > > return address;
> > > > @@ -3335,7 +3335,7 @@ unsigned long __weak
> > > pci_address_to_pio(phys_addr_t address)
> > > > {
> > > > #ifdef PCI_IOBASE
> > > > struct io_range *res;
> > > > - resource_size_t offset = 0;
> > > > + resource_size_t offset = PCIBIOS_MIN_IO;
> > > > unsigned long addr = -1;
> > > >
> > > > spin_lock(&io_range_lock);
> > > > diff --git a/include/linux/of_address.h
> b/include/linux/of_address.h
> > > > index 3786473..deec469 100644
> > > > --- a/include/linux/of_address.h
> > > > +++ b/include/linux/of_address.h
> > > > @@ -24,6 +24,23 @@ struct of_pci_range {
> > > > #define for_each_of_pci_range(parser, range) \
> > > > for (; of_pci_range_parser_one(parser, range);)
> > > >
> > > > +
> > > > +#ifndef indirect_io_enabled
> > > > +#define indirect_io_enabled indirect_io_enabled
> > > > +static inline bool indirect_io_enabled(void)
> > > > +{
> > > > + return false;
> > > > +}
> > > > +#endif
> > > > +
> > > > +#ifndef addr_is_indirect_io
> > > > +#define addr_is_indirect_io addr_is_indirect_io
> > > > +static inline int addr_is_indirect_io(u64 taddr)
> > > > +{
> > > > + return 0;
> > > > +}
> > > > +#endif
> > > > +
> > > > /* Translate a DMA address from device space to CPU space */
> > > > extern u64 of_translate_dma_address(struct device_node *dev,
> > > > const __be32 *in_addr);
> > > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > > index 0e49f70..7f6bbb6 100644
> > > > --- a/include/linux/pci.h
> > > > +++ b/include/linux/pci.h
> > > > @@ -2130,4 +2130,12 @@ static inline bool pci_ari_enabled(struct
> > > pci_bus *bus)
> > > > /* provide the legacy pci_dma_* API */
> > > > #include <linux/pci-dma-compat.h>
> > > >
> > > > +/*
> > > > + * define this macro here to refrain from compilation error for
> some
> > > > + * platforms. Please keep this macro at the end of this header
> file.
> > > > + */
> > > > +#ifndef PCIBIOS_MIN_IO
> > > > +#define PCIBIOS_MIN_IO 0
> > > > +#endif
> > > > +
> > > > #endif /* LINUX_PCI_H */
> > > > --
> > > > 1.9.1
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-
> pci"
> > > in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-
> info.html
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-10 16:07 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: mark.rutland@arm.com, benh@kernel.crashing.org,
catalin.marinas@arm.com, will.deacon@arm.com, Linuxarm,
lorenzo.pieralisi@arm.com, xuwei (O),
linux-serial@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, minyard@acm.org, liviu.dudau@arm.com,
John Garry, zourongrong@gmail.com, robh+dt@kernel.org,
bhelgaas@google.com, kantyzc@163.com, zhichang.yuan02@gmail.com,
linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8F5D75@lhreml507-mbx>
On Thursday, November 10, 2016 3:36:49 PM CET Gabriele Paoloni wrote:
>
> Where should we get the range from? For LPC we know that it is going
> Work on anything that is not used by PCI I/O space, and this is
> why we use [0, PCIBIOS_MIN_IO]
It should be allocated the same way we allocate PCI config space
segments. This is currently done with the io_range list in
drivers/pci/pci.c, which isn't perfect but could be extended
if necessary. Based on what others commented here, I'd rather
make the differences between ISA/LPC and PCI I/O ranges smaller
than larger.
> > Your current version has
> >
> > if (arm64_extio_ops->pfout) \
> > arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> > addr, value, sizeof(type)); \
> >
> > Instead, just subtract the start of the range from the logical
> > port number to transform it back into a bus-local port number:
>
> These accessors do not operate on IO tokens:
>
> If (arm64_extio_ops->start > addr || arm64_extio_ops->end < addr)
> addr is not going to be an I/O token; in fact patch 2/3 imposes that
> the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to PCIBIOS_MIN_IO
> we have free physical addresses that the accessors can operate on.
Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to refer to
the logical I/O tokens, the purpose of that macro is really meant
for allocating PCI I/O port numbers within the address space of
one bus.
Note that it's equally likely that whichever next platform needs
non-mapped I/O access like this actually needs them for PCI I/O space,
and that will use it on addresses registered to a PCI host bridge.
If we separate the two steps:
a) assign a range of logical I/O port numbers to a bus
b) register a set of helpers for redirecting logical I/O
port to a helper function
then I think the code will get cleaner and more flexible.
It should actually then be able to replace the powerpc
specific implementation.
Arnd
^ permalink raw reply
* Re: [RESEND PATCH] regulator: pwm: fix syntax errors in the examples
From: Mark Brown @ 2016-11-10 16:18 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Rob Herring,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478773527-10936-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 272 bytes --]
On Thu, Nov 10, 2016 at 11:25:27AM +0100, Peter Rosin wrote:
> While at it, clean up some other things as well.
This isn't a useful changelog, it's just saying that there's some
random changes for no reason. Please make proper patches with
changelogs that explain them.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH v2 0/6] Add support for STM32 ADC
From: Fabrice Gasnier @ 2016-11-10 16:18 UTC (permalink / raw)
To: linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, lars-Qo5EllUWu/uELgA04lAiVw,
knaack.h-Mmb7MZpHnFY, pmeerw-jW+XmwGofnusTnJN9+BGXg,
fabrice.gasnier-qxv4g6HH51o
This series adds support for STM32F4 ADC into IIO framework.
STM32F4 ADC is a 12-bit successive approximation analog-to-digital
converter with multiplexed input channels. Conversions can
be performed in single, continuous, scan or discontinuous mode.
Conversions can be launched in software or using hardware triggers.
This driver has been developed and tested on STM32F429 eval board.
It consist of a MFD core driver, to manage common resources shared
between up to 3 ADC instances.
Changes in v2:
- Replace single driver model by MFD approach, to handle up to 3 ADCs
as separate devices. Each ADC device then registers a unique IIO
device.
- Make driver as simple as possible for the first instance, to ease
review. For now, I dropped complexity by removing injected support,
triggered buffer mode, dmas.
- Removed abstraction layer (indirection routines, ops) as only stm32f4
is supported.
Fabrice Gasnier (6):
Documentation: dt-bindings: Document STM32 ADC DT bindings
mfd: stm32-adc: Add support for stm32 ADC
iio: adc: Add support for STM32 ADC
ARM: configs: stm32: enable ADC driver
ARM: dts: stm32f429: Add adc support
ARM: dts: stm32f429: enable adc on eval board
.../devicetree/bindings/iio/adc/st,stm32-adc.txt | 85 ++++
arch/arm/boot/dts/stm32429i-eval.dts | 25 +
arch/arm/boot/dts/stm32f429.dtsi | 49 ++
arch/arm/configs/stm32_defconfig | 3 +
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/stm32-adc.c | 525 +++++++++++++++++++++
drivers/mfd/Kconfig | 14 +
drivers/mfd/Makefile | 1 +
drivers/mfd/stm32-adc-core.c | 301 ++++++++++++
include/linux/mfd/stm32-adc-core.h | 52 ++
11 files changed, 1066 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
create mode 100644 drivers/iio/adc/stm32-adc.c
create mode 100644 drivers/mfd/stm32-adc-core.c
create mode 100644 include/linux/mfd/stm32-adc-core.h
--
1.9.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
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