Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Wed, Dec 16, 2015 at 09:05:35PM +0100, Maciej S. Szmigiero wrote:
> Hi Fabio,
> Hi Peter,
>
> On 16.12.2015 11:11, Fabio Estevam wrote:
> > Hi Peter,
> >
> > On Wed, Dec 16, 2015 at 2:11 AM, Peter Chen
> > wrote:
> >
> >> Thanks, Fabio, but I am curious how things like that? The USBOH3 clock
> >> is not opened, the usb driver will hang when it tries to access
> >> registers. If this clock is always on, then, why the system will
> >> hang later?
> >
> > I found the issue with your patch. You missed to add the pinctrl node.
> >
> > With the change below USB is functional in Udoo:
> >
> > --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > @@ -22,6 +22,8 @@
> >
> > usb_hub1 {
> > compatible = "generic-onboard-hub";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_usbh>;
> > clocks = <&clks IMX6QDL_CLK_CKO>;
> > reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> > reset-duration-us = <2>;
> >
>
> Thanks for your work, I didn't notice it previously (sorry).
>
> I can confirm, too that with Peter's patches and the above change
> the USB support works again on my UDOO DualLite board.
>
> However, I noticed that when you have host USB support configured to be
> build as modules then (due to its location under "if USB") it is only
> possible to compile generic onboard USB HUB as module, too.
>
> Then this module would need to be loaded before loading USB support
> (or quickly after it), otherwise USB enumeration would time out after
> few secs and loading it later wouldn't help.
Thanks for testing it, it maybe this hardware limitation.
The USB device should be back to work whenever do hardware reset,
otherwise, this reset is not clean.
>
> Currently, this driver doesn't really need any USB host support and
> is able to be compiled-in successfully regardless of USB host support
> configuration with just small change to Makefile and Kconfig.
>
> However I don't know if it is a design goal to not use USB host support
> or just a current development status, but if it doesn't really need it
> then it would be great if it could be selected to be build-in into kernel
> regardless of host USB support setting.
>
Yes, you are right, this driver is totally unrelated with ANY usb, but
it intends to handle general USB device which needs to have platform
control, and USB device is on the USB bus. Currently, if you are
USB stuff, you must depends of host or gadget support.
For this special hardware, you may have to define module load sequence
for your loadable support, it the current develop stage, maybe it can
be changed in future, I don't know when.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
On Wed, 2015-12-16 at 14:47 +0100, Hans Verkuil wrote:
> On 12/16/15 14:17, tiffany lin wrote:
> > Hi Hans,
> >
> >
> > On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
> >>
> >> On 12/15/15 14:51, tiffany lin wrote:
> >>> We are not familiar with v4l2-compliance utility, we will check how to
> >>> use it.
> >>
> >> It's part of v4l-utils.git (http://git.linuxtv.org/v4l-utils.git/). There
> >> is a
> >> fairly decent man page. It does exhaustive compliance tests for V4L2
> >> devices.
> >>
> >> That said, the support for memory-to-memory codec devices is not great, so
> >> I wouldn't
> >> trust any failures it reports when using the streaming tests (i.e. the
> >> --stream*
> >> options). By default just run 'v4l2-compliance -d /dev/videoX' to do the
> >> compliance
> >> test.
> >>
> >> Note: before I accept this driver I do want to see that compliance test
> >> output!
> >>
> > Got it. We will provide it in next version.
> > Now our driver is developed and run base on kernel v3.18.
> > V4L2 and vb2 have some difference between Linux 4.4-rc1 and 3.18 kernel.
> > Is it ok we provided test output base on v3.18 or we need to base on
> > 4.4-rc1?
>
> I'm actually not sure if the latest v4l2-compliance test suite will work with
> a 3.18
> kernel. so either you have to go back to an older version of v4l2-compliance
> that
> works with 3.18 (go back to commit 4a57509a8334aca6ca8e81cd3beb08d5be397dac,
> that
> might do the trick) or (and that's what I recommend) go with the latest
> kernel.
>
> For the media tree that is http://git.linuxtv.org/media_tree.git/log/.
>
> The final version of the patch has to be against that kernel anyway.
>
Got it. Thanks for your help, we will try it. ^_^
> > +}
> > +
> > +int m2mctx_venc_queue_init(void *priv, struct vb2_queue *src_vq,
> > + struct vb2_queue *dst_vq)
> > +{
> > + struct mtk_vcodec_ctx *ctx = priv;
> > + int ret;
> > +
> > + src_vq->type= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> > + src_vq->io_modes= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
>
> You're using videobuf2-dma-contig, so VB2_USERPTR is generally useless
> in that
> case. I would drop it.
>
> >>> Sorry, I don't get it.
> >>> We are using videobuf2-dma-contig, but we also using VB2_USERPTR.
> >>
> >> In that case the user pointer you pass in must point to physically
> >> contiguous
> >> memory. Which means you got it through some magic. Typically what should
> >> be used
> >> are dmabuf handles to pass buffers around between different subsystems.
> >>
> >> The use of VB2_USERPTR for that purpose is deprecated.
> >>
> >> Or am I misunderstanding you as well?
> >>
> > Our encoder support all three modes.
> > In case that A driver + Encode driver flow, OUTPUT buffer will be
> > VB2_DMABUF from A driver.
> > In case that read YCbCr frame data from file and encode them to bit
> > stream flow, we use VB2_USERPTR and VB2_MMAP.
> > In VB2_USERPTR case, videobuf2-dma-contig will help us get continuous
> > dma address.
> > Our chip has IOMMU and M4U that help us get continuous phy address for
> > encode HW.
> >
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-October/002525.html
>
> Ah, OK. Have you tested this with malloc()ed buffers? Just asking :-)
>
Yes. Actually we tested this with new()ed buffers. I think it default
call malloc.
> Regards,
>
> Hans
best regards,
Tiffany
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/8] irq: bcm2836: Add SMP support for the 2836
Hi Eric,
On Wed, Dec 16, 2015 at 03:55:09PM -0800, Eric Anholt wrote:
> @@ -226,6 +228,26 @@ static const struct irq_domain_ops
> bcm2836_arm_irqchip_intc_ops = {
> .xlate = irq_domain_xlate_onecell
> };
>
> +#ifdef CONFIG_SMP
Why not put this section under the existing '#ifdef CONFIG_SMP' just a few
lines above?
> +int __init bcm2836_smp_boot_secondary(unsigned int cpu,
> + struct task_struct *idle)
> +{
> + unsigned long secondary_startup_phys =
> + (unsigned long)virt_to_phys((void *)secondary_startup);
> +
> + dsb();
> + writel(secondary_startup_phys,
> +intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
> +
> + return 0;
> +}
> +
> +static const struct smp_operations bcm2836_smp_ops __initconst = {
> + .smp_boot_secondary = bcm2836_smp_boot_secondary,
> +};
> +
> +#endif
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
On 16.11.2015 16:43, Pavel Fedin wrote:
> This patch extends Exynos SROM controller driver with ability to configure
> controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
> which is connected via SROMc bank #3.
>
> With this patchset, support for the whole existing SMDK range can be added.
> Actually, only bank number is different.
>
> This patchset also depends on Exynos 5410 pinctrl support, introduced by
> patches 0003 and 0004 from this set:
> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
>
> Pinctrl support is necessary in order to correctly configure
> multifunctional pins of the Exynos chip.
>
Let me share the plan/status:
1. Currently Kukjin Kim is out of office (he told me he will be back on
Christmas).
2. I asked arm-soc people to pull my previous pull requests.
3. I applied this patchset to my branch:
next/stuff-late-not-split-per-branch
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch
4. This branch is not pushed to linux-next. I will sort it out if my
previous pull requests get in. I will be out of office for Christmas so
depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
not go into v4.5 (yay...).
5. If it does not get into v4.5, I will rebase it and proceed further
for v4.6.
If you have any questions, please let me know.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Input: add touchscreen support for TS-4800
Hi Damien,
On Thu, Dec 10, 2015 at 11:11:12AM -0500, Damien Riegel wrote:
> On this board, the touchscreen, an ads7843, is not handled directly by
> Linux but by a companion FPGA. This FPGA is memory-mapped and the IP
> design is very similar to the mk712.
>
> This commit adds the support for this IP.
>
> Signed-off-by: Damien Riegel
> ---
> drivers/input/touchscreen/Kconfig | 15 +++
> drivers/input/touchscreen/Makefile| 1 +
> drivers/input/touchscreen/ts4800-ts.c | 238
> ++
> 3 files changed, 254 insertions(+)
> create mode 100644 drivers/input/touchscreen/ts4800-ts.c
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index deb14c1..2d3b2f2 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -914,6 +914,21 @@ config TOUCHSCREEN_TOUCHIT213
>To compile this driver as a module, choose M here: the
>module will be called touchit213.
>
> +config TOUCHSCREEN_TS4800
> + tristate "TS-4800 touchscreen"
> + depends on HAS_IOMEM && OF
> + select MFD_SYSCON
You also need "select INPUT_POLLDEV" here.
> + help
> + Say Y here if you have a touchscreen on a TS-4800 board.
> +
> + On TS-4800, the touchscreen is not handled directly by Linux but by
> + a companion FPGA.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ts4800_ts.
> +
> config TOUCHSCREEN_TSC_SERIO
> tristate "TSC-10/25/40 serial touchscreen support"
> select SERIO
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index 1b79cc0..5d81ba8c 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
> +obj-$(CONFIG_TOUCHSCREEN_TS4800) += ts4800-ts.o
> obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO) += tsc40.o
> obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o
> obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
> diff --git a/drivers/input/touchscreen/ts4800-ts.c
> b/drivers/input/touchscreen/ts4800-ts.c
> new file mode 100644
> index 000..1e81b17
> --- /dev/null
> +++ b/drivers/input/touchscreen/ts4800-ts.c
> @@ -0,0 +1,238 @@
> +/*
> + * Touchscreen driver for the TS-4800 board
> + *
> + * Copyright (c) 2015 - Savoir-faire Linux
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* polling interval in ms*/
> +#define POLL_INTERVAL 3
> +
> +/* sensor values are 12-bit wide */
> +#define MAX_12BIT ((1 << 12) - 1)
> +
> +#define PENDOWN_MASK0x1
> +
> +#define X_OFFSET0x0
> +#define Y_OFFSET0x2
> +
> +struct ts4800_ts {
> + struct input_polled_dev *poll_dev;
> + struct device *dev;
> + charphys[32];
> +
> + void __iomem*base;
> + struct regmap *regmap;
> + unsigned intreg;
> + unsigned intbit;
> +
> + boolpendown;
> + int debounce;
> +};
> +
> +static void ts4800_ts_open(struct input_polled_dev *dev)
> +{
> + struct ts4800_ts *ts = dev->private;
> + int ret;
> +
> + ret = regmap_update_bits(ts->regmap, ts->reg,
> + 1 << ts->bit, 1 << ts->bit);
Instead of doing shift every time you can store already shifted value in
ts->bit.
> + if (ret)
> + dev_warn(ts->dev, "Failed to enable touchscreen\n");
> +}
> +
> +static void ts4800_ts_close(struct input_polled_dev *dev)
> +{
> + struct ts4800_ts *ts = dev->private;
> + int ret;
> +
> + ret = regmap_update_bits(ts->regmap, ts->reg,
> + 1 << ts->bit, 0);
> + if (ret)
> + dev_warn(ts->dev, "Failed to disable touchscreen\n");
> +
> +}
> +
> +static void ts4800_ts_poll(struct input_polled_dev *dev)
> +{
> + struct input_dev *input_dev = dev->input;
> + struct ts4800_ts *ts = dev->private;
> + u16 last_x = readw(ts->base + X_OFFSET);
> + u16 last_y = readw(ts->base + Y_OFFSET);
> + bool pendown = last_x & PENDOWN_MASK;
> +
> + if (!pendown && ts->pendown) {
> + ts->pendown = false;
> + ts->debounce = 1;
> + input_report_key(input_dev, BTN_TOUCH, 0);
> + input_sync(input_dev);
> + }
> +
> + if (pendown) {
> + if (ts->debounce) {
> + ts->debounce = 0;
This looks like a boolean, but I think having a counter for debounce is
more natural.
> + return;
> + }
> +
> + if (!ts->pendown) {
> + input_report_key(input_dev, BTN_TOUCH, 1);
> + ts->pendown = true;
> + }
> +
> + last_x = ((~last_x) >> 4) & MAX_12BIT;
> + last_y = ((~last_y) >> 4) & MAX_12BI
[PATCH 6/6] dt-bindings: add document for rk3036-vop
Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: devicetree@vger.kernel.org Signed-off-by: Mark Yao --- .../bindings/display/rockchip/rockchip-vop.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt index d15351f..5489b59 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt @@ -7,6 +7,7 @@ buffer to an external LCD interface. Required properties: - compatible: value should be one of the following "rockchip,rk3288-vop"; + "rockchip,rk3036-vop"; - interrupts: should contain a list of all VOP IP block interrupts in the order: VSYNC, LCD_SYSTEM. The interrupt specifier -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver
On Wed, 2015-12-16 at 12:48 +, Robin Murphy wrote:
> On 16/12/15 05:59, Yong Wu wrote:
> > On Tue, 2015-12-15 at 12:37 +, Robin Murphy wrote:
> >> On 15/12/15 03:28, Yong Wu wrote:
> >>> On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote:
> On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote:
[...]
> > Following your comment above, I test as below. Then the flows seems meet
> > the "best case" that the iommu core will help create default DMA domain.
> >
> > @@ -664,19 +636,41 @@ static int mtk_iommu_probe(struct platform_device
> > *pdev)
> > for (i = 0; i < larb_nr; i++) {
> > struct device_node *larbnode;
> > struct platform_device *plarbdev;
> >
> > larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
> > if (!larbnode)
> > return -EINVAL;
> >
> > plarbdev = of_find_device_by_node(larbnode);
> > of_node_put(larbnode);
> > - if (!plarbdev)
> > - return -EPROBE_DEFER;
> > + if (!plarbdev) {
> > + plarbdev = of_platform_device_create(larbnode,
> > NULL, platform_bus_type.dev_root);
> > + if (IS_ERR(pdev))
> > + return -EPROBE_DEFER;
> > + }
> > }
> >
> > I only add of_platform_device_create for the SMI local arbiter devices
> > here.
> >
> > This is a big improvement for us. If this is ok, I will send a quick
> > next version for this.
>
> In my opinion it's reasonable - we need the whole "IOMMU" to be ready,
Thanks.
> so if we already have to short-cut the creation of the M4U part it only
> seems fair to do the same for the SMI part. That said, would it work to
> just unconditionally poke the larbs in mtk_iommu_init_fn() before you
> poke the M4U itself? It would be nice to keep all that stuff together in
> the same place.
mtk_iommu_init_fn don't have the larb's "struct device_node". So I
cann't create its platform_device directly.
I have tried 2 method:
a) add a mtk_smi_larb_init_fn in the SMI patch.
static int mtk_smi_larb_init_fn(struct device_node *np)
{
struct platform_device *pdev;
pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
}
IOMMU_OF_DECLARE(mtk_smi_larb, "mediatek,mt8173-smi-larb",
mtk_smi_larb_init_fn);
This don't work. It will run after mtk_iommu_init_fn. then the larb's
platform_device also don't exist while m4u's probe.
b) Copy the code below to mtk_iommu_init_fn.
for (i = 0; i < larb_nr; i++) {
xxx
plarbdev = of_platform_device_create(larbnode,
NULL, platform_bus_type.dev_root);
}
It works. But then there are 2 same code of parsing the SMI local
arbiter(one is in mtk_iommu_init_fn, the other is in mtk_iommu_init_fn).
It looks not good. I think that the one I wrote in the previous mail is
better, It only add 3 lines, What's your opinion?
> > +static struct iommu_group *mtk_iommu_device_group(struct device *dev)
> > +{
> > + struct mtk_iommu_data *data;
> > + struct mtk_iommu_client_priv *priv;
> > +
> > + priv = dev->archdata.iommu;
> > + if (!priv)
> > + return ERR_PTR(-ENODEV);
> > +
> > + /* All the client devices are in the same m4u iommu-group */
> > + data = dev_get_drvdata(priv->m4udev);
> > + if (!data->m4u_group) {
> > + data->m4u_group = iommu_group_alloc();
> > + if (IS_ERR(data->m4u_group))
> > + dev_err(dev, "Failed to allocate M4U IOMMU
> > group\n");
> > + }
> > + return data->m4u_group;
> > +}
> >>
> >> As long as this works as expected, then AFAICS you shouldn't have to
> >> have *any* special-case behaviour or tracking of domains at all.
> >
> > We only need one iommu-group, one iommu domain here.
> >
> > What's the special-case behavior, how can we track of domains.
> > Could you help give me a example?
>
> The beauty of it is that you don't need to. If you guarantee all of an
> IOMMU's client devices are in the same group, you know you've only got
> one thing which can be attached to that IOMMU's domains. Therefore, you
> can freely allow as many domains as you like to *exist*, because there
> can never be more than one *active* at any given time - the core code
> enforces that the group is detached from one domain before being
> attached to another, and the driver's attach and detach calls just
> become responsible for switching the given domain's page table in and
> out of the actual hardware. I think it's pretty neat.
It seems that mtk-iommu can not detach/attach dynamically. the iommu
core don't support iommu_detach_device/iommu_attach_device whose
iommu-group have many devices.(Normally there is only one device in a
iommu-group).
[PATCH 12/12] ASoC: rsnd: add Multi channel support
From: Kuninori Morimoto
This patch adds Multi channel support on Renesas R-Car sound.
This patch is tested on Salvator-X board, but it can't use
Multi channel, because supported format is different between
codec chip and R-Car.
Thus, it was tested on board which doesn't mount codec chip,
with oscilloscope.
Signed-off-by: Kuninori Morimoto
---
.../devicetree/bindings/sound/renesas,rsnd.txt | 18
sound/soc/sh/rcar/core.c | 6 +-
sound/soc/sh/rcar/gen.c| 3 +
sound/soc/sh/rcar/rsnd.h | 15 ++-
sound/soc/sh/rcar/ssi.c| 114 -
sound/soc/sh/rcar/ssiu.c | 55 --
6 files changed, 194 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 162e94c..8ee0fa9 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -308,3 +308,21 @@ Example: simple sound card for TDM
sound-dai = <&xxx>;
};
};
+
+Example: simple sound card for Multi channel
+
+&rcar_sound {
+ pinctrl-0 = <&sound_pins &sound_clk_pins>;
+ pinctrl-names = "default";
+
+ /* Single DAI */
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+
+ rcar_sound,dai {
+ dai0 {
+ playback = <&ssi0 &ssi1 &ssi2 &src0 &dvc0>;
+ };
+ };
+};
diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 7781cef..ca05a0a 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -215,7 +215,11 @@ int rsnd_get_slot_num(struct rsnd_dai_stream *io)
int rsnd_get_slot_width(struct rsnd_dai_stream *io)
{
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
- int chan = runtime->channels / rsnd_get_slot_num(io);
+ int chan = runtime->channels;
+
+ /* Multi channel Mode */
+ if (rsnd_ssi_multi_slaves(io))
+ chan /= rsnd_get_slot_num(io);
/* TDM Extend Mode needs 8ch */
if (chan == 6)
diff --git a/sound/soc/sh/rcar/gen.c b/sound/soc/sh/rcar/gen.c
index 7c5485e..c7aee9e 100644
--- a/sound/soc/sh/rcar/gen.c
+++ b/sound/soc/sh/rcar/gen.c
@@ -226,6 +226,9 @@ static int rsnd_gen2_probe(struct rsnd_priv *priv)
const static struct rsnd_regmap_field_conf conf_ssiu[] = {
RSND_GEN_S_REG(SSI_MODE0, 0x800),
RSND_GEN_S_REG(SSI_MODE1, 0x804),
+ RSND_GEN_S_REG(SSI_MODE2, 0x808),
+ RSND_GEN_S_REG(SSI_CONTROL, 0x810),
+
/* FIXME: it needs SSI_MODE2/3 in the future */
RSND_GEN_M_REG(SSI_BUSIF_MODE, 0x0,0x80),
RSND_GEN_M_REG(SSI_BUSIF_ADINR, 0x4,0x80),
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index f803e14..317dd79 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -47,6 +47,8 @@ enum rsnd_reg {
RSND_REG_SSI_MODE, /* Gen2 only */
RSND_REG_SSI_MODE0,
RSND_REG_SSI_MODE1,
+ RSND_REG_SSI_MODE2,
+ RSND_REG_SSI_CONTROL,
RSND_REG_SSI_CTRL, /* Gen2 only */
RSND_REG_SSI_BUSIF_MODE,/* Gen2 only */
RSND_REG_SSI_BUSIF_ADINR, /* Gen2 only */
@@ -181,7 +183,10 @@ enum rsnd_mod_type {
RSND_MOD_CTU,
RSND_MOD_CMD,
RSND_MOD_SRC,
- RSND_MOD_SSIP, /* SSI parent */
+ RSND_MOD_SSIM3, /* SSI multi 3 */
+ RSND_MOD_SSIM2, /* SSI multi 2 */
+ RSND_MOD_SSIM1, /* SSI multi 1 */
+ RSND_MOD_SSIP, /* SSI parent */
RSND_MOD_SSI,
RSND_MOD_SSIU,
RSND_MOD_MAX,
@@ -542,6 +547,7 @@ void rsnd_ssi_remove(struct rsnd_priv *priv);
struct rsnd_mod *rsnd_ssi_mod_get(struct rsnd_priv *priv, int id);
int rsnd_ssi_is_dma_mode(struct rsnd_mod *mod);
int rsnd_ssi_use_busif(struct rsnd_dai_stream *io);
+u32 rsnd_ssi_multi_slaves(struct rsnd_dai_stream *io);
#define rsnd_ssi_is_pin_sharing(io)\
__rsnd_ssi_is_pin_sharing(rsnd_io_to_mod_ssi(io))
@@ -549,10 +555,9 @@ int __rsnd_ssi_is_pin_sharing(struct rsnd_mod *mod);
#define rsnd_ssi_of_node(priv) \
of_get_child_by_name(rsnd_priv_to_dev(priv)->of_node, "rcar_sound,ssi")
-#define rsnd_parse_connect_ssi(rdai, playback, capture)
\
- rsnd_parse_connect_common(rdai, rsnd_ssi_mod_get, \
- rsnd_ssi_of_node(rsnd_rdai_to_priv(rdai)), \
- playback, capture)
+void rsnd_parse_connect_ssi(struct rsnd_dai *rdai,
+ struct device_node *playback,
+ struct device_node *capture);
/*
* R-Car SSIU
dif
[PATCH 10/12] ASoC: rsnd: add missing DT example for Simple Card
From: Kuninori Morimoto
Signed-off-by: Kuninori Morimoto
---
.../devicetree/bindings/sound/renesas,rsnd.txt | 40 ++
1 file changed, 40 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 59cebfb..bb9f33405 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -249,3 +249,43 @@ rcar_sound: sound@ec50 {
};
};
};
+
+Example: simple sound card
+
+ rsnd_ak4643: sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,format = "left_j";
+ simple-audio-card,bitclock-master = <&sndcodec>;
+ simple-audio-card,frame-master = <&sndcodec>;
+
+ sndcpu: simple-audio-card,cpu {
+ sound-dai = <&rcar_sound>;
+ };
+
+ sndcodec: simple-audio-card,codec {
+ sound-dai = <&ak4643>;
+ clocks = <&audio_clock>;
+ };
+ };
+
+&rcar_sound {
+ pinctrl-0 = <&sound_pins &sound_clk_pins>;
+ pinctrl-names = "default";
+
+ /* Single DAI */
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+
+ rcar_sound,dai {
+ dai0 {
+ playback = <&ssi0 &src2 &dvc0>;
+ capture = <&ssi1 &src3 &dvc1>;
+ };
+ };
+};
+
+&ssi1 {
+ shared-pin;
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] ASoC: rsnd: add missing DT example for Simple Card with TDM
From: Kuninori Morimoto
Signed-off-by: Kuninori Morimoto
---
.../devicetree/bindings/sound/renesas,rsnd.txt| 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index bb9f33405..162e94c 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -289,3 +289,22 @@ Example: simple sound card
&ssi1 {
shared-pin;
};
+
+Example: simple sound card for TDM
+
+ rsnd_tdm: sound {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,format = "left_j";
+ simple-audio-card,bitclock-master = <&sndcodec>;
+ simple-audio-card,frame-master = <&sndcodec>;
+
+ sndcpu: simple-audio-card,cpu {
+ sound-dai = <&rcar_sound>;
+ dai-tdm-slot-num = <6>;
+ };
+
+ sndcodec: simple-audio-card,codec {
+ sound-dai = <&xxx>;
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Thu, Dec 17, 2015 at 12:13:07AM +0100, Arnd Bergmann wrote:
> On Wednesday 16 December 2015 16:59:39 Rob Herring wrote:
> > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote:
> > > On Monday 14 December 2015 15:26:11 Peter Chen wrote:
> >
> > I agree on doing it properly, but am not sure that pwrseq binding for
> > MMC is proper. The pwrseq binding is fairly limited and working around
> > the driver model IMO. Hubs may also need I2C setup which I don't think
> > could be done generically other than some defined sequence of i2c
> > transactions. The current project I'm working on needs to use I2C to
> > configure the hub to use HSIC mode for example. I really think we need
> > a pre-probe driver hook to handle this. That would allow device
> > specific setup to live in the driver.
> >
> > Perhaps a more simple approach would be just forcing driver probe if a
> > DT node is present. I'm not all that familiar with USB drivers, but
> > presumably there is some setup before probe like setting the USB
> > device address. We'd have to allow doing that later during probe.
>
> Yes, good idea. I was also advocating that approach for MMC at some
> point, but the power sequencing made it in the end.
>
Currently, my design is much like Rob proposal's. I will populate all
children device under HUB's node (controller = 1st level hub), and
each special onboard USB device needs a platform driver, it can be
probed according to compatible string, and at its probe, it can register
itself as usb device if needed, and handle properties described at
its node. Sample code like below:
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 8263fc1..7451f7d 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -590,6 +590,16 @@
&usbh1 {
vbus-supply = <®_usb_h1_vbus>;
status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hub: usb2415@01 {
+ compatible = "generic-onboard-hub";
+ reg = <0x01>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ reset-duration-us = <10>;
+ };
};
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5e32ce7..2107b12 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1334,6 +1335,20 @@ static int hub_post_reset(struct usb_interface *intf)
return 0;
}
+static int hub_of_children_register(struct usb_device *hdev)
+{
+ struct device *dev;
+
+ if (hdev->parent)
+ dev = &hdev->dev;
+ else
+ dev = bus_to_hcd(hdev->bus)->self.controller;
+ if (!dev->of_node)
+ return 0;
+
+ return of_platform_populate(dev->of_node, NULL, NULL, dev);
+}
+
static int hub_configure(struct usb_hub *hub,
struct usb_endpoint_descriptor *endpoint)
{
@@ -1701,6 +1716,7 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+ int ret;
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1820,6 +1836,12 @@ descriptor_error:
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
+ ret = hub_of_children_register(hdev);
+ if (ret) {
+ dev_err(&hdev->dev, "Failed to register child device\n");
+ return ret;
+ }
+
if (hub_configure(hub, endpoint) >= 0)
return 0;
At onboard general usb hub driver:
static const struct of_device_id usb_hub_generic_dt_ids[] = {
{.compatible = "generic-onboard-hub"},
{ },
};
MODULE_DEVICE_TABLE(of, usb_hub_generic_dt_ids);
static struct platform_driver usb_hub_generic_driver = {
.probe = usb_hub_generic_probe,
.remove = usb_hub_generic_remove,
.driver = {
.name = "usb_hub_generic_onboard",
.of_match_table = usb_hub_generic_dt_ids,
},
};
static int __init usb_hub_generic_init(void)
{
return platform_driver_register(&usb_hub_generic_driver);
}
subsys_initcall(usb_hub_generic_init);
static void __exit usb_hub_generic_exit(void)
{
platform_driver_unregister(&usb_hub_generic_driver);
}
module_exit(usb_hub_generic_exit);
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hi,
On 2015년 12월 17일 11:16, Chanwoo Choi wrote:
> Hi Sergei,
>
> On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
>> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
>> enable a system with an integrated USB OTG dual-role transceiver to
>> function as an USB OTG dual-role device. In addition to sensing/controlling
>> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
>> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
>> pin -- there's no real OTG controller, only host and gadget USB controllers
>> sharing the same USB bus; however, we'd like to allow host or gadget
>> drivers to be loaded depending on the cable type, hence the need for the
>> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
>> (however, we aren't currently interested in them), the OFFVBUS# signal is
>> controlled by the host controllers, there's also the SHDN# signal wired to
>> a GPIO, it should be driven high for the normal operation.
>>
>> Signed-off-by: Sergei Shtylyov
>>
>> ---
>> Changes in version 3:
>> - reformatted the change log.
>>
>> Changes in version 2:
>> - added the USB gadget cable support;
>> - added the remove() driver method which drives SHDN# GPIO low to save power;
>> - dropped vendor prefix from the ID GPIO property name;
>> - changed the GPIO property name suffix to "-gpios";
>> - switched to usign extcon_set_cable_state_() API;
>> - switched to using the gpiod/sleeping 'gpiolib' APIs;
>> - addded error messages to max3355_probe();
>> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
>> - renamed 'ret' variable to 'err' in max3355_probe();
>> - expanded the Kconfig entry help text;
>> - added vendor name to the patch summary, the bindings document, the Kconfig
>> entry, the driver heading comment, the module description, and the change
>> log;
>> - fixed up and reformatted the change log.
>>
>> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
>> drivers/extcon/Kconfig |8
>> drivers/extcon/Makefile |1
>> drivers/extcon/extcon-max3355.c | 153
>>
>> 4 files changed, 183 insertions(+)
>>
[snip]
>> +return 0;
>> +}
>> +
>> +static int max3355_remove(struct platform_device *pdev)
>> +{
>> +struct max3355_data *data = platform_get_drvdata(pdev);
>> +
>> +gpiod_set_value_cansleep(data->shdn_gpiod, 0);
Don't need to handle the 'shdn' gpio on resume/suspend funtcion?
But, if the interrput of id gpio is used for wakeup source,
there is no reason to handle it for suspend mode.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
Hi Sergei,
On 2015년 12월 17일 03:07, Sergei Shtylyov wrote:
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
> entry, the driver heading comment, the module description, and the change
> log;
> - fixed up and reformatted the change log.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
> drivers/extcon/Kconfig |8
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 153
>
> 4 files changed, 183 insertions(+)
>
> Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> + id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: renesas/drivers/extcon/Kconfig
> ===
> --- renesas.orig/drivers/extcon/Kconfig
> +++ renesas/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
> detector and switch.
>
> +config EXTCON_MAX3355
> + tristate "Maxim MAX3355 USB OTG EXTCON Support"
> + help
> + If you say yes here you get support for the USB OTG role detection by
> + MAX3355. The MAX3355 chip integrates a charge pump and comparators to
> + enable a system with an integrated USB OTG dual-role transceiver to
> + function as an USB OTG dual-role device.
> +
> config EXTCON_MAX77693
> tristate "Maxim MAX77693 EXTCON Support"
> depends on MFD_MAX77693 && INPUT
> Index: renesas/drivers/extcon/Makefile
> ===
> --- renesas.orig/drivers/extcon/Makefile
> +++ renesas/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA) += extcon-a
> obj-$(CONFIG_EXTCON_AXP288) += extcon-axp288.o
> obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
> obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
> +obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX77843)+= extcon-max77843.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> Index: renesas/drivers/extcon/extcon-max3355.c
> ===
> --- /dev/null
> +++ renesas/drivers/extcon/extcon-max3355.c
> @@ -0,0 +1,153 @@
> +/*
> + * Maxim Integrated MAX3355 USB OTG chip extco
Re: [GIT PULL 0/9] ARM: EXYNOS: Pull request for v4.5
On 17.12.2015 10:43, Krzysztof Kozlowski wrote: > On 02.12.2015 10:39, Krzysztof Kozlowski wrote: >> Hi Kukjin, >> >> A lot of stuff for v4.5 with 3 dependencies split into >> separate tags. The need for dependency is explained both >> in merge-commit and in description of a tag which is using >> the dependency. > > Hi everyone, > > It's been like two weeks... we are after v4.4-rc5 and Christmas season > is coming... there are some dependencies here and even more stuff waits > out of queue for this pull request (moving SROM and PMU to drivers/soc, > cpufreq for Exynos542x). > > What I want to say is that I am really not sure whether further waiting > is beneficial... > All these patches have been boiling in linux-next for some time (through > my tree). > > > Are there any comments about this pull request? Ordering of branches? > Weird looking tags? Bugs? etc.? Anything waits in your tree Kukjin? > > > Maybe this could be pulled directly by arm-soc folks? > Actually in the same time I sent this mail I got an ack from Kukjin (his Business Trip to China extended further than planned), so: Arnd, Kevin and Olof, Could you pull this for v4.5 or share your comments? The number of tags is not that scary... just some dependencies split across 3 tags. Best regards, Krzysztof > >> >> The order goes like (but of course dependencies >> could be pulled all at once at beginning): >> 1. tags/samsung-dt-syscon-restart-4.5 >> 2. tags/samsung-soc-4.5 >> 3. tags/samsung-clk-arm64-symbols-4.5 >> 4. tags/samsung-soc64-4.5 >> 5. tags/samsung-drivers-4.5 >> 6. tags/samsung-clk-exynos4-4.5 >> 7. tags/samsung-dt-4.5 >> 8. tags/samsung-dt64-4.5 >> 9. tags/samsung-defconfig-4.5 >> >> I split dependencies to three tags so clock or other folks could >> easily grab them if needed. >> >> Please share your comments or pull as early as possible as we have here >> some more dependencies than usual. >> >> >> Kind regards, >> Krzysztof >> > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.
On 16-12-15, 21:29, Dawei Chien wrote: > Use Intelligent Power Allocation (IPA) technical to add dynamic power model > for binding CPU thermal zone. The power allocator governor allocates power > budget to control CPU temperature. > > Power Allocator governor is able to keep SOC temperature within a defined > temperature range to avoid SOC overheat and keep it's performance. > mt8173-cpufreq.c need to register its' own power model with power allocator > thermal governor, so that power allocator governor can allocates suitable > power budget to control CPU temperature. > > Binding document is refer to this patchset > https://lkml.org/lkml/2015/11/30/239 > > Change since V5: > 1. Remove thermal sensor ID from phandles Though you should have included this in the new version, but still Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 0/9] ARM: EXYNOS: Pull request for v4.5
On 02.12.2015 10:39, Krzysztof Kozlowski wrote: > Hi Kukjin, > > A lot of stuff for v4.5 with 3 dependencies split into > separate tags. The need for dependency is explained both > in merge-commit and in description of a tag which is using > the dependency. Hi everyone, It's been like two weeks... we are after v4.4-rc5 and Christmas season is coming... there are some dependencies here and even more stuff waits out of queue for this pull request (moving SROM and PMU to drivers/soc, cpufreq for Exynos542x). What I want to say is that I am really not sure whether further waiting is beneficial... All these patches have been boiling in linux-next for some time (through my tree). Are there any comments about this pull request? Ordering of branches? Weird looking tags? Bugs? etc.? Anything waits in your tree Kukjin? Maybe this could be pulled directly by arm-soc folks? Best regards, Krzysztof > > The order goes like (but of course dependencies > could be pulled all at once at beginning): > 1. tags/samsung-dt-syscon-restart-4.5 > 2. tags/samsung-soc-4.5 > 3. tags/samsung-clk-arm64-symbols-4.5 > 4. tags/samsung-soc64-4.5 > 5. tags/samsung-drivers-4.5 > 6. tags/samsung-clk-exynos4-4.5 > 7. tags/samsung-dt-4.5 > 8. tags/samsung-dt64-4.5 > 9. tags/samsung-defconfig-4.5 > > I split dependencies to three tags so clock or other folks could > easily grab them if needed. > > Please share your comments or pull as early as possible as we have here > some more dependencies than usual. > > > Kind regards, > Krzysztof > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/5] Add reboot notifier driver for rockchip platform
On Mon, Dec 14, 2015 at 2:30 AM, Andy Yan wrote: > On 2015年12月12日 05:29, Heiko Stübner wrote: >> Am Mittwoch, 18. November 2015, 17:47:24 schrieb Andy Yan: >>> >>> rockchip platform have a protocol to pass the kernel reboot >>> mode to bootloader by some special registers when system reboot. >>> By this way the bootloader can take different action according >>> to the different kernel reboot mode, for example, command >>> "reboot loader" will reboot the board to rockusb mode, this is >>> a very convenient way to get the board enter download mode. >>> And Android system also use this protocol to pass "recovery"、 >>> “fastboot” reboot mode to bootloader. In upstream land, We found >>> tegra platform also use this mechanism. >>> >>> Before this version, I have sent two Series, which can be found >>> at [0] [1] >>> [0] https://patchwork.kernel.org/patch/7140751/ >>> [1] https://patchwork.kernel.org/patch/7153531/ >> >> just so it doesn't get lost, this ties into a slightly more generic >> approach, >> John Stultz is doing for the android reboot reasons: >> >> http://thread.gmane.org/gmane.linux.kernel/2103447 >> >> The only difference is that we'd need to use the pmu syscon for it. >> >> > Very glad to see your work on this. And your work is more generic than > my. > So hope we can share the code. As you can see, the rockchip platform > use > a GRF or PMU register to store the reboot reason. So maybe we need a > phandle > in the DT node to describe it. Yea. I need to figure out the best way to represent these various methods in DT. Apologies for not being super responsive here. Been a bit heads down trying to finish up some items before holiday break. >From some of Arnd's comments, it sounds like we may need a larger generic subsystem for kernel to firmware communications here. So more then likely I'll not have a chance to take another swing at this after the new year. So if in the meantime you want to try to take my code and rework it, or extend your code in a similar way, I'll not take any offence. :) thanks -john -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
On Tue, Dec 15, 2015 at 11:03:48AM +0100, Geert Uytterhoeven wrote:
> Hi David,
>
> On Tue, Dec 15, 2015 at 7:00 AM, David Gibson
> wrote:
> >> If the only property needed is the partition table offset, it can be
> >> encoded
> >> in the unit-address, and the "reg" property:
> >>
> >> partitions {
> >>
> >> partition-table@ {
> >> reg = <0 ...>;
> >> ...
> >> };
> >>
> >> ...
> >> };
> >
> > Urgh.. and that's abusing the unit address.
>
> Why? The partition is part of the FLASH. In this respect, it doesn't differ
> from other hardcoded partitions using the same DT syntax.
> It would just have a compatible value indicating it's a partition
> table.
Ah.. yes, fair enough. I'd forgotten that the encoding of explicit
partitions in the device tree already established the address space
here as being the flash blocks. So, no, it's not an abuse of unit
address.
Doesn't help for partition table types which require scanning the
device, of course.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
2015-12-17 3:07 GMT+09:00 Sergei Shtylyov :
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
> entry, the driver heading comment, the module description, and the change
> log;
> - fixed up and reformatted the change log.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
> drivers/extcon/Kconfig |8
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 153
>
> 4 files changed, 183 insertions(+)
>
> Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
Could you add some indentation to the wrapped line for this property?
For readability.
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
Ditto.
Why this property lacks the vendor prefix i(n comparison to shdn-gpios
which has the prefix)?
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> + id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: renesas/drivers/extcon/Kconfig
> ===
> --- renesas.orig/drivers/extcon/Kconfig
> +++ renesas/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port
> accessory
> detector and switch.
>
> +config EXTCON_MAX3355
> + tristate "Maxim MAX3355 USB OTG EXTCON Support"
> + help
> + If you say yes here you get support for the USB OTG role detection
> by
> + MAX3355. The MAX3355 chip integrates a charge pump and comparators
> to
> + enable a system with an integrated USB OTG dual-role transceiver to
> + function as an USB OTG dual-role device.
> +
> config EXTCON_MAX77693
> tristate "Maxim MAX77693 EXTCON Support"
> depends on MFD_MAX77693 && INPUT
> Index: renesas/drivers/extcon/Makefile
> ===
> --- renesas.orig/drivers/extcon/Makefile
> +++ renesas/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
> obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
> obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
> obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
> +obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
> obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> Index: renesas/drivers/extcon/extcon-max3355.c
> =
Re: [PATCH v3 2/4] ARM: bcm2835: add rpi power domain driver
Ulf Hansson writes: > On 16 December 2015 at 02:27, Krzysztof Kozlowski > wrote: >> 2015-12-16 10:11 GMT+09:00 Sebastian Reichel : >>> Hi, >>> >>> On Tue, Dec 15, 2015 at 04:53:31PM -0800, Eric Anholt wrote: >> There are 6 power domain drivers in >> arch/arm, 3 in drivers/clk, and 3 in drivers/soc. > > If we ever have to support a different architecture which happens to use > a similar power domain, then we want it to be in a location which makes > it easy for sharing it in the first place. As it stands today, it does > not seem useful to me to have this code in arch/arm/mach-bcm/ at all. > > Maybe there is room from a drivers/power/domains/ of some kind? >>> >>> I like the idea, but let's include generic power domain maintainers >>> in this discussion, as I suggested here (I got a power domain driver >>> patch for drivers/power just a few days ago): >>> >>> https://lkml.org/lkml/2015/12/15/815 >>> >>> Also somebody would have to step up to maintain that directory. >> >> This could go into drivers/soc. We put there a lot of mach-specific >> stuff which we want to make a little more generic (like generic enough >> multiplatform, multiarchitecture etc). Rockchip has its own power >> domains there. Dove and Mediatek seem as well but I am not sure. Some >> other architectures keep this still in arm/mach (exynos, ux500, zx, >> imx, s34c64xx, shmobile) but this looks more of like a legacy choice. > > Agree, drivers/soc is good. OK, I've resent with a move to drivers/soc/bcm/. signature.asc Description: PGP signature
Re: [PATCH v2 0/8] Raspberry Pi 2 support.
Arnd Bergmann writes: > On Wednesday 16 December 2015 15:55:07 Eric Anholt wrote: >> This is a major rewrite of the previous Raspberry Pi 2 submission. >> SMP support is now included, and the DT includes are cleaned up to >> avoid massive duplication. >> >> The branch (based on 4.4-rc5, to get the USB regression fixes) can be >> found at: >> >> https://github.com/anholt/linux/tree/bcm2836-4.4 > > Looks all good to me, but when we get the pull request, I'd strongly > prefer to have that based on -rc3 or earlier. > > What commit is the USB regression fix you refer to above? Is that in a > branch that is -rc3 based? Maybe you can rebase the changes on top > of that branch, to minimize the amount of backmerges? Top 4 commits of drivers/usb/dwc2 for 4.4-rc5 (possibly not all of them are required, but it's what I've been using). I've been using cherry-picks of them on top of my various branches for testing, but pi2 was going to be rebased so many times in the process of cleanup that I put it underneath my development branch instead. I've been doing pull requests for my stuff on -rc1 tags. It sucks for bisecting any breakage I produce when I can't boot that directly, but I don't see a good way to avoid this kind of pain other than getting some Pis into kernel-ci.org so we can catch regressions earlier. signature.asc Description: PGP signature
[PATCH v4 0/4] Raspberry Pi power domains
Update from v3 to move the driver under drivers/soc. I've placed it under drivers/soc/bcm since that's how the other drivers under drivers/soc are structured. Alexander Aring (3): ARM: bcm2835: add rpi power domain driver dt-bindings: add rpi power domain driver bindings ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. Eric Anholt (1): ARM: bcm2835: Define two new packets from the latest firmware. .../bindings/soc/bcm/raspberrypi,bcm2835-power.txt | 47 arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 + arch/arm/boot/dts/bcm2835.dtsi | 2 +- drivers/soc/Kconfig| 1 + drivers/soc/Makefile | 1 + drivers/soc/bcm/Kconfig| 9 + drivers/soc/bcm/Makefile | 1 + drivers/soc/bcm/raspberrypi-power.c| 247 + include/dt-bindings/soc/raspberrypi-power.h| 41 include/soc/bcm2835/raspberrypi-firmware.h | 2 + 10 files changed, 361 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt create mode 100644 drivers/soc/bcm/Kconfig create mode 100644 drivers/soc/bcm/Makefile create mode 100644 drivers/soc/bcm/raspberrypi-power.c create mode 100644 include/dt-bindings/soc/raspberrypi-power.h -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] dt-bindings: add rpi power domain driver bindings
From: Alexander Aring
This patch adds devicetree tree bindings for the Raspberry Pi power
domain driver.
Signed-off-by: Alexander Aring
Acked-by: Rob Herring
Signed-off-by: Eric Anholt
---
v2: Add the new domains present in v2 to the list.
v4: Move to soc/ instead of arm/, to follow the driver's move.
.../bindings/soc/bcm/raspberrypi,bcm2835-power.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt
diff --git
a/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt
b/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 000..30942cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,47 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible: Should be "raspberrypi,bcm2835-power".
+- firmware:Reference to the RPi firmware device node.
+- #power-domain-cells: Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_I2C0
+ RPI_POWER_DOMAIN_I2C1
+ RPI_POWER_DOMAIN_I2C2
+ RPI_POWER_DOMAIN_VIDEO_SCALER
+ RPI_POWER_DOMAIN_VPU1
+ RPI_POWER_DOMAIN_HDMI
+ RPI_POWER_DOMAIN_USB
+ RPI_POWER_DOMAIN_VEC
+ RPI_POWER_DOMAIN_JPEG
+ RPI_POWER_DOMAIN_H264
+ RPI_POWER_DOMAIN_V3D
+ RPI_POWER_DOMAIN_ISP
+ RPI_POWER_DOMAIN_UNICAM0
+ RPI_POWER_DOMAIN_UNICAM1
+ RPI_POWER_DOMAIN_CCP2RX
+ RPI_POWER_DOMAIN_CSI2
+ RPI_POWER_DOMAIN_CPI
+ RPI_POWER_DOMAIN_DSI0
+ RPI_POWER_DOMAIN_DSI1
+ RPI_POWER_DOMAIN_TRANSPOSER
+ RPI_POWER_DOMAIN_CCP2TX
+ RPI_POWER_DOMAIN_CDP
+ RPI_POWER_DOMAIN_ARM
+
+Example:
+
+power: power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <&firmware>;
+ #power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+ power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
From: Alexander Aring
This connects the USB driver to the USB power domain, so that USB can
actually be turned on at boot if the bootloader didn't do it for us.
Signed-off-by: Alexander Aring
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 11 +++
arch/arm/boot/dts/bcm2835.dtsi | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..7982d22 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include
#include "bcm2835.dtsi"
/ {
@@ -20,6 +21,12 @@
compatible = "raspberrypi,bcm2835-firmware";
mboxes = <&mailbox>;
};
+
+ power: power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <&firmware>;
+ #power-domain-cells = <1>;
+ };
};
};
@@ -60,3 +67,7 @@
status = "okay";
bus-width = <4>;
};
+
+&usb {
+ power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..6d62af0 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -177,7 +177,7 @@
status = "disabled";
};
- usb@7e98 {
+ usb: usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
interrupts = <1 9>;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] ARM: bcm2835: add rpi power domain driver
From: Alexander Aring
This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.
This patch is the combined work of Eric Anholt (who wrote USB support
inside of the Raspberry Pi firmware driver, and wrote the non-USB
domain support) and Alexander Aring (who separated the original USB
work out from the firmware driver).
Signed-off-by: Alexander Aring
Signed-off-by: Eric Anholt
---
v2: Add support for power domains other than USB, using the new
firmware interface, reword commit message (changes by Eric)
v3: Restructure as a builtin driver, and drop
of_genpd_add_provider_onecell error handling to avoid
pm_genpd_exit() dependency until that API can be settled. Clean
up copyright header, add missing ISP initialization, and fix typo
in transposer's name.
v4: Move to drivers/soc/bcm/, move include to dt-bindings/soc/, set up
Makefile for the drivers/soc/bcm following clk/'s model.
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile| 1 +
drivers/soc/bcm/Kconfig | 9 +
drivers/soc/bcm/Makefile| 1 +
drivers/soc/bcm/raspberrypi-power.c | 247
include/dt-bindings/soc/raspberrypi-power.h | 41 +
6 files changed, 300 insertions(+)
create mode 100644 drivers/soc/bcm/Kconfig
create mode 100644 drivers/soc/bcm/Makefile
create mode 100644 drivers/soc/bcm/raspberrypi-power.c
create mode 100644 include/dt-bindings/soc/raspberrypi-power.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 4e853ed..8441426 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
menu "SOC (System On Chip) specific Drivers"
+source "drivers/soc/bcm/Kconfig"
source "drivers/soc/brcmstb/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index f2ba2e9..f3f955c 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -2,6 +2,7 @@
# Makefile for the Linux Kernel SOC specific device drivers.
#
+obj-y += bcm/
obj-$(CONFIG_SOC_BRCMSTB) += brcmstb/
obj-$(CONFIG_MACH_DOVE)+= dove/
obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
diff --git a/drivers/soc/bcm/Kconfig b/drivers/soc/bcm/Kconfig
new file mode 100644
index 000..5ba1827
--- /dev/null
+++ b/drivers/soc/bcm/Kconfig
@@ -0,0 +1,9 @@
+config RASPBERRYPI_POWER
+ bool "Raspberry Pi power domain driver"
+ depends on ARCH_BCM2835 || COMPILE_TEST
+ depends on RASPBERRYPI_FIRMWARE
+ select PM_GENERIC_DOMAINS if PM
+ select PM_GENERIC_DOMAINS_OF if PM
+ help
+ This enables support for the RPi power domains which can be enabled
+ or disabled via the RPi firmware.
diff --git a/drivers/soc/bcm/Makefile b/drivers/soc/bcm/Makefile
new file mode 100644
index 000..63aa3eb
--- /dev/null
+++ b/drivers/soc/bcm/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_RASPBERRYPI_POWER)+= raspberrypi-power.o
diff --git a/drivers/soc/bcm/raspberrypi-power.c
b/drivers/soc/bcm/raspberrypi-power.c
new file mode 100644
index 000..d5bab06
--- /dev/null
+++ b/drivers/soc/bcm/raspberrypi-power.c
@@ -0,0 +1,247 @@
+/* (C) 2015 Pengutronix, Alexander Aring
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Authors:
+ * Alexander Aring
+ * Eric Anholt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Firmware indices for the old power domains interface. Only a few
+ * of them were actually implemented.
+ */
+#define RPI_OLD_POWER_DOMAIN_USB 3
+#define RPI_OLD_POWER_DOMAIN_V3D 10
+
+struct rpi_power_domain {
+ u32 domain;
+ bool enabled;
+ bool old_interface;
+ struct generic_pm_domain base;
+ struct rpi_firmware *fw;
+};
+
+struct rpi_power_domains {
+ bool has_new_interface;
+ struct genpd_onecell_data xlate;
+ struct rpi_firmware *fw;
+ struct rpi_power_domain domains[RPI_POWER_DOMAIN_COUNT];
+};
+
+/*
+ * Packet definition used by RPI_FIRMWARE_SET_POWER_STATE and
+ * RPI_FIRMWARE_SET_DOMAIN_STATE
+ */
+struct rpi_power_domain_packet {
+ u32 domain;
+ u32 on;
+} __packet;
+
+/*
+ * Asks the firmware to enable or disable power on a specific power
+ * domain.
+ */
+static int rpi_firmware_set_power(struct rpi_power_domain *rpi_domain, bool on)
+{
+ struct rpi_power_domain_packet packet;
+
+ packet.domain = rpi_domain->domain;
+ packet.on = on;
+ return rpi_firmware_property(rpi_domain->fw,
+rpi_domain->old_interface ?
+RPI_FIRMWARE_SET_POWER_STATE :
+
[PATCH v4 1/4] ARM: bcm2835: Define two new packets from the latest firmware.
These packets give us direct access to the firmware's power management
code, as opposed to GET/SET_POWER_STATE packets that only had a couple
of domains implemented.
Signed-off-by: Eric Anholt
---
include/soc/bcm2835/raspberrypi-firmware.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
b/include/soc/bcm2835/raspberrypi-firmware.h
index c07d74a..3fb3571 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -72,10 +72,12 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_ENABLE_QPU = 0x00030012,
RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
+ RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
RPI_FIRMWARE_SET_CLOCK_STATE =0x00038001,
RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
RPI_FIRMWARE_SET_VOLTAGE =0x00038003,
RPI_FIRMWARE_SET_TURBO = 0x00038009,
+ RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/8] Raspberry Pi 2 support.
On Wednesday 16 December 2015 15:55:07 Eric Anholt wrote: > This is a major rewrite of the previous Raspberry Pi 2 submission. > SMP support is now included, and the DT includes are cleaned up to > avoid massive duplication. > > The branch (based on 4.4-rc5, to get the USB regression fixes) can be > found at: > > https://github.com/anholt/linux/tree/bcm2836-4.4 Looks all good to me, but when we get the pull request, I'd strongly prefer to have that based on -rc3 or earlier. What commit is the USB regression fix you refer to above? Is that in a branch that is -rc3 based? Maybe you can rebase the changes on top of that branch, to minimize the amount of backmerges? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/8] ARM: bcm2835: Add devicetree for bcm2836 and Raspberry Pi 2 B
The Pi 2 B ends up like a Pi 1 B+, with the same peripherals and
pinout, but the CPU and memory layout changed to use the 2836.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 35
arch/arm/boot/dts/bcm2836.dtsi| 77 +++
2 files changed, 112 insertions(+)
create mode 100644 arch/arm/boot/dts/bcm2836-rpi-2-b.dts
create mode 100644 arch/arm/boot/dts/bcm2836.dtsi
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
new file mode 100644
index 000..ff94666
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -0,0 +1,35 @@
+/dts-v1/;
+#include "bcm2836.dtsi"
+#include "bcm2835-rpi.dtsi"
+
+/ {
+ compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
+ model = "Raspberry Pi 2 Model B";
+
+ memory {
+ reg = <0 0x4000>;
+ };
+
+ leds {
+ act {
+ gpios = <&gpio 47 0>;
+ };
+
+ pwr {
+ label = "PWR";
+ gpios = <&gpio 35 0>;
+ default-state = "keep";
+ linux,default-trigger = "default-on";
+ };
+ };
+};
+
+&gpio {
+ pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
+
+ /* I2S interface */
+ i2s_alt0: i2s_alt0 {
+ brcm,pins = <18 19 20 21>;
+ brcm,function = ;
+ };
+};
diff --git a/arch/arm/boot/dts/bcm2836.dtsi b/arch/arm/boot/dts/bcm2836.dtsi
new file mode 100644
index 000..6693118
--- /dev/null
+++ b/arch/arm/boot/dts/bcm2836.dtsi
@@ -0,0 +1,77 @@
+#include "bcm283x.dtsi"
+
+/ {
+ compatible = "brcm,bcm2836";
+
+ soc {
+ ranges = <0x7e00 0x3f00 0x100>,
+<0x4000 0x4000 0x1000>;
+ dma-ranges = <0xc000 0x 0x3f00>;
+
+ local_intc: local_intc {
+ compatible = "brcm,bcm2836-l1-intc";
+ reg = <0x4000 0x100>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&local_intc>;
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupt-parent = <&local_intc>;
+ interrupts = <9>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupt-parent = <&local_intc>;
+ interrupts = <0>, // PHYS_SECURE_PPI
+<1>, // PHYS_NONSECURE_PPI
+<3>, // VIRT_PPI
+<2>; // HYP_PPI
+ always-on;
+ };
+
+ cpus: cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ v7_cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf00>;
+ clock-frequency = <8>;
+ };
+
+ v7_cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf01>;
+ clock-frequency = <8>;
+ };
+
+ v7_cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf02>;
+ clock-frequency = <8>;
+ };
+
+ v7_cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf03>;
+ clock-frequency = <8>;
+ };
+ };
+};
+
+/* Make the BCM2835-style global interrupt controller be a child of the
+ * CPU-local interrupt controller.
+ */
+&intc {
+ compatible = "brcm,bcm2836-armctrl-ic";
+ interrupt-parent = <&local_intc>;
+ interrupts = <8>;
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] ARM: bcm2835: Add a compat string for bcm2836 machine probe
Supporting the 2836 requires using the new interrupt controller, which
we have support for.
Signed-off-by: Eric Anholt
---
arch/arm/mach-bcm/board_bcm2835.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-bcm/board_bcm2835.c
b/arch/arm/mach-bcm/board_bcm2835.c
index 0f7b9ea..834d676 100644
--- a/arch/arm/mach-bcm/board_bcm2835.c
+++ b/arch/arm/mach-bcm/board_bcm2835.c
@@ -36,7 +36,12 @@ static void __init bcm2835_init(void)
}
static const char * const bcm2835_compat[] = {
+#ifdef CONFIG_ARCH_MULTI_V6
"brcm,bcm2835",
+#endif
+#ifdef CONFIG_ARCH_MULTI_V7
+ "brcm,bcm2836",
+#endif
NULL
};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/8] ARM: bcm2835: Split the DT for peripherals from the DT for the CPU
The set of peripherals remained constant across bcm2835 (Raspberry Pi
1) and bcm2836 (Raspberry Pi 2), but the CPU was swapped out. Split
the files so that we can include just peripheral setup in 2836.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835.dtsi | 194 +--
arch/arm/boot/dts/{bcm2835.dtsi => bcm283x.dtsi} | 7 +-
2 files changed, 6 insertions(+), 195 deletions(-)
copy arch/arm/boot/dts/{bcm2835.dtsi => bcm283x.dtsi} (96%)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index aef64de..b83b326 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,206 +1,14 @@
-#include
-#include
-#include "skeleton.dtsi"
+#include "bcm283x.dtsi"
/ {
compatible = "brcm,bcm2835";
- model = "BCM2835";
- interrupt-parent = <&intc>;
-
- chosen {
- bootargs = "earlyprintk console=ttyAMA0";
- };
soc {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
ranges = <0x7e00 0x2000 0x0200>;
dma-ranges = <0x4000 0x 0x2000>;
- timer@7e003000 {
- compatible = "brcm,bcm2835-system-timer";
- reg = <0x7e003000 0x1000>;
- interrupts = <1 0>, <1 1>, <1 2>, <1 3>;
- /* This could be a reference to BCM2835_CLOCK_TIMER,
-* but we don't have the driver using the common clock
-* support yet.
-*/
- clock-frequency = <100>;
- };
-
- dma: dma@7e007000 {
- compatible = "brcm,bcm2835-dma";
- reg = <0x7e007000 0xf00>;
- interrupts = <1 16>,
-<1 17>,
-<1 18>,
-<1 19>,
-<1 20>,
-<1 21>,
-<1 22>,
-<1 23>,
-<1 24>,
-<1 25>,
-<1 26>,
-<1 27>,
-<1 28>;
-
- #dma-cells = <1>;
- brcm,dma-channel-mask = <0x7f35>;
- };
-
- intc: interrupt-controller@7e00b200 {
- compatible = "brcm,bcm2835-armctrl-ic";
- reg = <0x7e00b200 0x200>;
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- watchdog@7e10 {
- compatible = "brcm,bcm2835-pm-wdt";
- reg = <0x7e10 0x28>;
- };
-
- clocks: cprman@7e101000 {
- compatible = "brcm,bcm2835-cprman";
- #clock-cells = <1>;
- reg = <0x7e101000 0x2000>;
-
- /* CPRMAN derives everything from the platform's
-* oscillator.
-*/
- clocks = <&clk_osc>;
- };
-
- rng@7e104000 {
- compatible = "brcm,bcm2835-rng";
- reg = <0x7e104000 0x10>;
- };
-
- mailbox: mailbox@7e00b800 {
- compatible = "brcm,bcm2835-mbox";
- reg = <0x7e00b880 0x40>;
- interrupts = <0 1>;
- #mbox-cells = <0>;
- };
-
- gpio: gpio@7e20 {
- compatible = "brcm,bcm2835-gpio";
- reg = <0x7e20 0xb4>;
- /*
-* The GPIO IP block is designed for 3 banks of GPIOs.
-* Each bank has a GPIO interrupt for itself.
-* There is an overall "any bank" interrupt.
-* In order, these are GIC interrupts 17, 18, 19, 20.
-* Since the BCM2835 only has 2 banks, the 2nd bank
-* interrupt output appears to be mirrored onto the
-* 3rd bank's interrupt signal.
-* So, a bank0 interrupt shows up on 17, 20, and
-* a bank1 interrupt shows up on 18, 19, 20!
-*/
- interrupts = <2 17>, <2 18>, <2 19>, <2 20>;
-
- gpio-controller;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
- };
-
- uart0: uart@7
[PATCH v2 5/8] ARM: bcm2835: Move the CPU/peripheral include out of common RPi DT.
For Raspberry Pi 2, we want to use the same general pin assignment
bits, but need to use bcm2836.dtsi for the CPU instead.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 --
5 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index b2bff43..228614f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -1,4 +1,5 @@
/dts-v1/;
+#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
/ {
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index 668442b..ef54050 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -1,4 +1,5 @@
/dts-v1/;
+#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
/ {
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index eab8b591..86f1f2f 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -1,4 +1,5 @@
/dts-v1/;
+#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
/ {
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts
b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index ff6b2d1..4859e9d 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -1,4 +1,5 @@
/dts-v1/;
+#include "bcm2835.dtsi"
#include "bcm2835-rpi.dtsi"
/ {
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 3572f03..3afb9fe 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,5 +1,3 @@
-#include "bcm2835.dtsi"
-
/ {
memory {
reg = <0 0x1000>;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] ARM: bcm2835: Add Kconfig support for bcm2836
This should be a complete port of bcm2835 functionality to bcm2836 (Raspberry Pi 2). Signed-off-by: Eric Anholt --- v2: Implement Arnd's feedback to not split to ARCH_BCM2836, and instead use more conditionals in ARCH_BCM2835. Also reduce diff between 2835 and 2836. arch/arm/Kconfig.debug | 10 -- arch/arm/boot/dts/Makefile | 3 ++- arch/arm/mach-bcm/Kconfig | 8 3 files changed, 14 insertions(+), 7 deletions(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 259c0ca..957b876 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -143,7 +143,12 @@ choice config DEBUG_BCM2835 bool "Kernel low-level debugging on BCM2835 PL011 UART" - depends on ARCH_BCM2835 + depends on ARCH_BCM2835 && ARCH_MULTI_V6 + select DEBUG_UART_PL01X + + config DEBUG_BCM2836 + bool "Kernel low-level debugging on BCM2836 PL011 UART" + depends on ARCH_BCM2835 && ARCH_MULTI_V7 select DEBUG_UART_PL01X config DEBUG_BCM_5301X @@ -1402,6 +1407,7 @@ config DEBUG_UART_PHYS default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2 default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3 default 0x20201000 if DEBUG_BCM2835 + default 0x3f201000 if DEBUG_BCM2836 default 0x3e00 if DEBUG_BCM_KONA_UART default 0x4000e400 if DEBUG_LL_UART_EFM32 default 0x40081000 if DEBUG_LPC18XX_UART0 @@ -1485,7 +1491,7 @@ config DEBUG_UART_VIRT default 0xfbe0 if ARCH_EBSA110 default 0xf001 if DEBUG_ASM9260_UART default 0xf01fb000 if DEBUG_NOMADIK_UART - default 0xf0201000 if DEBUG_BCM2835 + default 0xf0201000 if DEBUG_BCM2835 || DEBUG_BCM2836 default 0xf1000300 if DEBUG_BCM_5301X default 0xf1002000 if DEBUG_MT8127_UART0 default 0xf1006000 if DEBUG_MT6589_UART0 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 30bbc37..54e8f6b 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -60,7 +60,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \ bcm2835-rpi-b.dtb \ bcm2835-rpi-b-rev2.dtb \ bcm2835-rpi-b-plus.dtb \ - bcm2835-rpi-a-plus.dtb + bcm2835-rpi-a-plus.dtb \ + bcm2836-rpi-2-b.dtb dtb-$(CONFIG_ARCH_BCM_5301X) += \ bcm4708-asus-rt-ac56u.dtb \ bcm4708-asus-rt-ac68u.dtb \ diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 8c53c55..d7cada9 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -122,17 +122,17 @@ config ARCH_BCM_MOBILE_SMP comment "Other Architectures" config ARCH_BCM2835 - bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 + bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 || ARCH_MULTI_V7 select ARCH_REQUIRE_GPIOLIB select ARM_AMBA - select ARM_ERRATA_411920 + select ARM_ERRATA_411920 if ARCH_MULTI_V6 select ARM_TIMER_SP804 select CLKSRC_OF select PINCTRL select PINCTRL_BCM2835 help - This enables support for the Broadcom BCM2835 SoC. This SoC is - used in the Raspberry Pi and Roku 2 devices. + This enables support for the Broadcom BCM2835 and BCM2836 SoCs. + This SoC is used in the Raspberry Pi and Roku 2 devices. config ARCH_BCM_63XX bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7 -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/8] dt-bindings: Add root properties for Raspberry Pi 2
Signed-off-by: Eric Anholt --- Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt index c78576b..11d3056 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt @@ -26,6 +26,10 @@ Raspberry Pi Model B+ Required root node properties: compatible = "raspberrypi,model-b-plus", "brcm,bcm2835"; +Raspberry Pi 2 Model B +Required root node properties: +compatible = "raspberrypi,2-model-b", "brcm,bcm2836"; + Raspberry Pi Compute Module Required root node properties: compatible = "raspberrypi,compute-module", "brcm,bcm2835"; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/8] irq: bcm2836: Fix initialization of the LOCAL_IRQ_CNT*IRQ timers
The irqchip's register area includes the the setup for the timer's
scaling factors, and for the platform we want a fixed configuration of
these registers.
Signed-off-by: Eric Anholt
---
drivers/irqchip/irq-bcm2836.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index f687082..6ec125e 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -21,6 +21,9 @@
#include
#include
+#define LOCAL_CONTROL 0x000
+#define LOCAL_PRESCALER0x008
+
/*
* The low 2 bits identify the CPU that the GPU IRQ goes to, and the
* next 2 bits identify the CPU that the GPU FIQ goes to.
@@ -237,6 +240,27 @@ bcm2836_arm_irqchip_smp_init(void)
#endif
}
+/*
+ * The LOCAL_IRQ_CNT* timer firings are based off of the external
+ * oscillator with some scaling. The firmware sets up CNTFRQ to
+ * report 19.2Mhz, but doesn't set up the scaling registers.
+ */
+static void bcm2835_init_local_timer_frequency(void)
+{
+ /*
+* Set the timer to source from the 19.2Mhz crystal clock (bit
+* 8 unset), and only increment by 1 instead of 2 (bit 9
+* unset).
+*/
+ writel(0, intc.base + LOCAL_CONTROL);
+
+ /*
+* Set the timer prescaler to 1:1 (timer freq = input freq *
+* 2**31 / prescaler)
+*/
+ writel(0x8000, intc.base + LOCAL_PRESCALER);
+}
+
static int __init bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
struct device_node
*parent)
{
@@ -246,6 +270,8 @@ static int __init
bcm2836_arm_irqchip_l1_intc_of_init(struct device_node *node,
node->full_name);
}
+ bcm2835_init_local_timer_frequency();
+
intc.domain = irq_domain_add_linear(node, LAST_IRQ + 1,
&bcm2836_arm_irqchip_intc_ops,
NULL);
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] irq: bcm2836: Add SMP support for the 2836
From: Andrea Merello
The firmware sets the secondaries spinning waiting for a non-NULL
value to show up in the last IPI mailbox.
The original SMP port from the downstream tree was done by Andrea, and
Eric cleaned it up/rewrote it a few times from there.
Signed-off-by: Andrea Merello
Signed-off-by: Eric Anholt
---
drivers/irqchip/irq-bcm2836.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 6ec125e..c5ef4df 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -53,14 +53,16 @@
/* Same status bits as above, but for FIQ. */
#define LOCAL_FIQ_PENDING0 0x070
/*
- * Mailbox0 write-to-set bits. There are 16 mailboxes, 4 per CPU, and
+ * Mailbox write-to-set bits. There are 16 mailboxes, 4 per CPU, and
* these bits are organized by mailbox number and then CPU number. We
* use mailbox 0 for IPIs. The mailbox's interrupt is raised while
* any bit is set.
*/
#define LOCAL_MAILBOX0_SET00x080
-/* Mailbox0 write-to-clear bits. */
+#define LOCAL_MAILBOX3_SET00x08c
+/* Mailbox write-to-clear bits. */
#define LOCAL_MAILBOX0_CLR00x0c0
+#define LOCAL_MAILBOX3_CLR00x0cc
#define LOCAL_IRQ_CNTPSIRQ 0
#define LOCAL_IRQ_CNTPNSIRQ1
@@ -226,6 +228,26 @@ static const struct irq_domain_ops
bcm2836_arm_irqchip_intc_ops = {
.xlate = irq_domain_xlate_onecell
};
+#ifdef CONFIG_SMP
+int __init bcm2836_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ unsigned long secondary_startup_phys =
+ (unsigned long)virt_to_phys((void *)secondary_startup);
+
+ dsb();
+ writel(secondary_startup_phys,
+ intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
+
+ return 0;
+}
+
+static const struct smp_operations bcm2836_smp_ops __initconst = {
+ .smp_boot_secondary = bcm2836_smp_boot_secondary,
+};
+
+#endif
+
static void
bcm2836_arm_irqchip_smp_init(void)
{
@@ -237,6 +259,7 @@ bcm2836_arm_irqchip_smp_init(void)
register_cpu_notifier(&bcm2836_arm_irqchip_cpu_notifier);
set_smp_cross_call(bcm2836_arm_irqchip_send_ipi);
+ smp_set_ops(&bcm2836_smp_ops);
#endif
}
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] Raspberry Pi 2 support.
This is a major rewrite of the previous Raspberry Pi 2 submission.
SMP support is now included, and the DT includes are cleaned up to
avoid massive duplication.
The branch (based on 4.4-rc5, to get the USB regression fixes) can be
found at:
https://github.com/anholt/linux/tree/bcm2836-4.4
Andrea Merello (1):
irq: bcm2836: Add SMP support for the 2836
Eric Anholt (7):
irq: bcm2836: Fix initialization of the LOCAL_IRQ_CNT*IRQ timers
dt-bindings: Add root properties for Raspberry Pi 2
ARM: bcm2835: Split the DT for peripherals from the DT for the CPU
ARM: bcm2835: Move the CPU/peripheral include out of common RPi DT.
ARM: bcm2835: Add devicetree for bcm2836 and Raspberry Pi 2 B
ARM: bcm2835: Add a compat string for bcm2836 machine probe
ARM: bcm2835: Add Kconfig support for bcm2836
.../devicetree/bindings/arm/bcm/brcm,bcm2835.txt | 4 +
arch/arm/Kconfig.debug | 10 +-
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 1 +
arch/arm/boot/dts/bcm2835-rpi-b.dts| 1 +
arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 -
arch/arm/boot/dts/bcm2835.dtsi | 194 +
...{bcm2835-rpi-b-plus.dts => bcm2836-rpi-2-b.dts} | 9 +-
arch/arm/boot/dts/bcm2836.dtsi | 77
arch/arm/boot/dts/{bcm2835.dtsi => bcm283x.dtsi} | 7 +-
arch/arm/mach-bcm/Kconfig | 8 +-
arch/arm/mach-bcm/board_bcm2835.c | 5 +
drivers/irqchip/irq-bcm2836.c | 53 +-
15 files changed, 168 insertions(+), 208 deletions(-)
copy arch/arm/boot/dts/{bcm2835-rpi-b-plus.dts => bcm2836-rpi-2-b.dts} (72%)
create mode 100644 arch/arm/boot/dts/bcm2836.dtsi
copy arch/arm/boot/dts/{bcm2835.dtsi => bcm283x.dtsi} (96%)
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/19] ARM: dts: s5pv210: replace legacy *,wakeup property with wakeup-source
2015-10-21 19:10 GMT+09:00 Sudeep Holla : > Though the keyboard and other driver will continue to support the legacy > "gpio-key,wakeup", "linux,input-wakeup" boolean property to enable the > wakeup source, "wakeup-source" is the new standard binding. > > This patch replaces all the legacy wakeup properties with the unified > "wakeup-source" property in order to avoid any futher copy-paste > duplication. > > Cc: Marek Szyprowski > Cc: Kukjin Kim > Cc: linux-samsung-...@vger.kernel.org > Signed-off-by: Sudeep Holla > --- > arch/arm/boot/dts/s5pv210-aquila.dts | 4 ++-- > arch/arm/boot/dts/s5pv210-goni.dts | 4 ++-- > arch/arm/boot/dts/s5pv210-smdkv210.dts | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] ARM: dts: exynos: replace legacy *,wakeup property with wakeup-source
On 21.10.2015 19:10, Sudeep Holla wrote:
> Though the keyboard and other driver will continue to support the legacy
> "gpio-key,wakeup", "linux-keypad,wakeup" boolean property to enable the
> wakeup source, "wakeup-source" is the new standard binding.
>
> This patch replaces all the legacy wakeup properties with the unified
> "wakeup-source" property in order to avoid any futher copy-paste
> duplication.
>
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Sudeep Holla
> ---
> arch/arm/boot/dts/exynos3250-monk.dts | 6 +++---
> arch/arm/boot/dts/exynos3250-rinato.dts | 6 +++---
> arch/arm/boot/dts/exynos4210-origen.dts | 10 +-
> arch/arm/boot/dts/exynos4210-smdkv310.dts | 2 +-
> arch/arm/boot/dts/exynos4210-trats.dts | 2 +-
> arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 ++--
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 +-
> arch/arm/boot/dts/exynos4412-odroidx.dts| 2 +-
> arch/arm/boot/dts/exynos4412-origen.dts | 2 +-
> arch/arm/boot/dts/exynos4412-smdk4412.dts | 2 +-
> arch/arm/boot/dts/exynos4412-trats2.dts | 4 ++--
> arch/arm/boot/dts/exynos5250-arndale.dts| 12 ++--
> arch/arm/boot/dts/exynos5250-snow.dts | 4 ++--
> arch/arm/boot/dts/exynos5250-spring.dts | 4 ++--
> arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 +-
> arch/arm/boot/dts/exynos5420-peach-pit.dts | 4 ++--
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++--
> 17 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
> b/arch/arm/boot/dts/exynos3250-monk.dts
> index 540a0adf2be6..b77ea2163a0a 100644
> --- a/arch/arm/boot/dts/exynos3250-monk.dts
> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
> @@ -43,7 +43,7 @@
> linux,code = ;
> label = "power key";
> debounce-interval = <10>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
> };
>
> @@ -67,7 +67,7 @@
> interrupt-parent = <&gpx1>;
> interrupts = <5 0>;
> reg = <0x25>;
> - wakeup;
> + wakeup-source;
>
> muic: max77836-muic {
> compatible = "maxim,max77836-muic";
> @@ -184,7 +184,7 @@
> interrupt-parent = <&gpx0>;
> interrupts = <7 0>;
> reg = <0x66>;
> - wakeup;
> + wakeup-source;
>
> s2mps14_osc: clocks {
> compatible = "samsung,s2mps14-clk";
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 41a5fafb9aa9..7acd11d2d957 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -43,7 +43,7 @@
> linux,code = ;
> label = "power key";
> debounce-interval = <10>;
> - gpio-key,wakeup;
> + wakeup-source;
> };
> };
>
> @@ -58,7 +58,7 @@
> interrupt-parent = <&gpx1>;
> interrupts = <5 0>;
> reg = <0x25>;
> - wakeup;
> + wakeup-source;
>
> muic: max77836-muic {
> compatible = "maxim,max77836-muic";
> @@ -245,7 +245,7 @@
> interrupt-parent = <&gpx0>;
> interrupts = <7 0>;
> reg = <0x66>;
> - wakeup;
> + wakeup-source;
I think here and in Monk board these four "wakeup" properties are bogus,
not parsed by driver. Instead wakeup is always initialized to true.
Anyway fixing this is not part of this patch but instead this should be
fixed in separate commit. Here everything looks good:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11
Hi Matt, Any chance to get an Ack from you for this patch? -- Stefan On 2015-12-07 13:51, Stefan Agner wrote: > GPLv2-only devicetrees make reuse difficult for software components > licensed under a different license. > > The consensus is that a GPL/X11 dual-license should allow all necessary > uses, so relicense the vf610-twr.dts file to this combination. > > CCs were acquired using (updated some email addresses): > git shortlog -sne --no-merges arch/arm/boot/dts/vf610-cosmic.dts > > CC: Matt Porter > Acked-by: Shawn Guo > Acked-by: Cory Tusar > Acked-by: Olof Johansson > Signed-off-by: Stefan Agner > --- > arch/arm/boot/dts/vf610-cosmic.dts | 40 > ++ > 1 file changed, 36 insertions(+), 4 deletions(-) > > diff --git a/arch/arm/boot/dts/vf610-cosmic.dts > b/arch/arm/boot/dts/vf610-cosmic.dts > index 5447f25..d0559c1 100644 > --- a/arch/arm/boot/dts/vf610-cosmic.dts > +++ b/arch/arm/boot/dts/vf610-cosmic.dts > @@ -2,10 +2,42 @@ > * Copyright 2013 Freescale Semiconductor, Inc. > * Copyright 2013 Linaro Limited > * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > + * 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 free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * version 2 as published by the Free Software Foundation. > + * > + * This file is distributed in the hope that it will be useful > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * 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 , 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/; -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/19] ARM: dts: exynos: replace legacy *,wakeup property with wakeup-source
On 16.12.2015 19:32, Sudeep Holla wrote: > > > On 15/12/15 23:32, Krzysztof Kozlowski wrote: >> On 16.12.2015 01:35, Sudeep Holla wrote: >>> >>> >>> On 21/10/15 11:10, Sudeep Holla wrote: Though the keyboard and other driver will continue to support the legacy "gpio-key,wakeup", "linux-keypad,wakeup" boolean property to enable the wakeup source, "wakeup-source" is the new standard binding. This patch replaces all the legacy wakeup properties with the unified "wakeup-source" property in order to avoid any futher copy-paste duplication. Cc: Kukjin Kim Cc: Krzysztof Kozlowski >>> >>> Ping, do you prefer taking via your tree or should I send to armsoc >>> directly ? >> >> Usually it depends on the dependencies... but: >> 1. I just received this patch - 12/19. > > Sorry for that. The initial idea was to show all the changes but merge > the binding and dependencies first, so didn't cc all. > >> 2. No cover letter, no other patches, no explanation about any >> dependencies or other related changes. Nothing. Just one patch. > > Yes this was initially posted as part of the series, but only > dependencies were merged for v4.4 > >> 3. The patch mentions new standard binding. Was the new binding already >> merged? Or is it part of these series? What about backward compatibility? > > Not a brand new binding, but made existing one a standard so that we > don't continue to be creative and generate more bindings for the same > thing. Yes binding and dependent patches are already in mainline. And > yes backward compatibility is maintained as mentioned in the commit > message. That explains everything, thanks. We'll take it through samsung-soc, just give me some time for review. As for other patch - the s5pv210 - I did not get it directly but I think I can find it on list subscription archives. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Wednesday 16 December 2015 16:59:39 Rob Herring wrote: > On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote: > > On Monday 14 December 2015 15:26:11 Peter Chen wrote: > > I agree on doing it properly, but am not sure that pwrseq binding for > MMC is proper. The pwrseq binding is fairly limited and working around > the driver model IMO. Hubs may also need I2C setup which I don't think > could be done generically other than some defined sequence of i2c > transactions. The current project I'm working on needs to use I2C to > configure the hub to use HSIC mode for example. I really think we need > a pre-probe driver hook to handle this. That would allow device > specific setup to live in the driver. > > Perhaps a more simple approach would be just forcing driver probe if a > DT node is present. I'm not all that familiar with USB drivers, but > presumably there is some setup before probe like setting the USB > device address. We'd have to allow doing that later during probe. Yes, good idea. I was also advocating that approach for MMC at some point, but the power sequencing made it in the end. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
On Mon, Dec 14, 2015 at 3:35 AM, Arnd Bergmann wrote: > On Monday 14 December 2015 15:26:11 Peter Chen wrote: >> Hi all, >> >> There is a known issue that the USB code can't handle USB HUB's >> external pins well, in that case, it may cause some onboard >> USB HUBs can't work since their PHY's clock or reset pin needs to >> operate. >> >> The user reported this issue at below: >> http://www.spinics.net/lists/linux-usb/msg131502.html >> >> In this patch set, I add a generic onboard USB HUB driver to >> handle this problem, the external signals will be configured >> before usb controller's initialization, it much likes we did >> it at board code before. >> >> The user needs to add this generic hub node at dts to support it. >> >> @The udoo users, help to test please. > > I still think need to do this properly by representing the hub > device as a USB device, using power sequencing code like MMC does. I agree on doing it properly, but am not sure that pwrseq binding for MMC is proper. The pwrseq binding is fairly limited and working around the driver model IMO. Hubs may also need I2C setup which I don't think could be done generically other than some defined sequence of i2c transactions. The current project I'm working on needs to use I2C to configure the hub to use HSIC mode for example. I really think we need a pre-probe driver hook to handle this. That would allow device specific setup to live in the driver. Perhaps a more simple approach would be just forcing driver probe if a DT node is present. I'm not all that familiar with USB drivers, but presumably there is some setup before probe like setting the USB device address. We'd have to allow doing that later during probe. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver
On Thu, Dec 03, 2015 at 03:35:22PM +0200, Stanimir Varbanov wrote:
> From: Stanimir Varbanov
>
> The PCIe driver reuse the Designware common code for host
> and MSI initialization, and also program the Qualcomm
> application specific registers.
>
> Signed-off-by: Stanimir Varbanov
> Signed-off-by: Stanimir Varbanov
> ---
> MAINTAINERS |7 +
> drivers/pci/host/Kconfig | 10 +
> drivers/pci/host/Makefile|1 +
> drivers/pci/host/pcie-qcom.c | 624
> ++
> +#define PCIE20_CAP 0x70
> +#define PCIE20_CAP_LINKCTRLSTATUS(PCIE20_CAP + 0x10)
> +#define PCIE20_CAP_LINKCTRLSTATUS_LINK_UPBIT(29)
This looks like it could be referring to a standard PCIe Capability;
could you use the existing PCI_EXP_LNKSTA and PCI_EXP_LNKSTA_DLLLA
symbols here? And readw() instead of readl()?
> +static int qcom_pcie_enable_link_training(struct qcom_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + u32 val;
> + int ret;
> +
> + /* enable link training */
> + val = readl(pcie->elbi + PCIE20_ELBI_SYS_CTRL);
> + val |= PCIE20_ELBI_SYS_CTRL_LT_ENABLE;
> + writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
> +
> + /* wait for up to 100ms for the link to come up */
> + ret = readl_poll_timeout(pcie->elbi + PCIE20_ELBI_SYS_STTS, val,
> + val & XMLH_LINK_UP, LINKUP_DELAY_US,
> + LINKUP_TIMEOUT_US);
> +
> + if (ret < 0 || !dw_pcie_link_up(&pcie->pp)) {
> + dev_err(dev, "link initialization failed\n");
> + return -ETIMEDOUT;
> + }
> +
> + return 0;
> +}
This looks a lot like the *_establish_link() functions in other
DesignWare-based drivers. Can you make it look even more similar,
e.g., by renaming it to qcom_pcie_establish_link() and maybe moving
some of the PHY functionality here?
readl_poll_timeout() is nice and avoids the hand-coded timeout loop
the other drivers use. But is there benefit in checking for
XMLH_LINK_UP, or could you simply poll dw_pcie_link_up() like the
others do? If it's sufficient, I'd prefer using dw_pcie_link_up()
by itself because it's a little more generic.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] clk: rockchip: rk3036: enable the CLK_IGNORE_UNUSED flag for aclk_vio
Am Mittwoch, 16. Dezember 2015, 16:27:18 schrieb Caesar Wang: > From: Yakir Yang > > ACLK_VIO is the noc bus clock for display module, display cann't > read data from ddr without this clock enabled. > > Due to it shouldn't belong to any driver, but we need it enabled, > so just mark it as the CLK_IGNORE_UNUSED flag. > > Signed-off-by: Yakir Yang > Signed-off-by: Caesar Wang applied to my clk-branch for 4.5 Thanks Heiko -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] PCI: qcom: Add Qualcomm PCIe controller driver
Hi Stan, On Tue, Dec 15, 2015 at 10:24:07AM +0200, Stanimir Varbanov wrote: > On 12/03/2015 03:35 PM, Stanimir Varbanov wrote: > > From: Stanimir Varbanov > > > > The PCIe driver reuse the Designware common code for host > > and MSI initialization, and also program the Qualcomm > > application specific registers. > > > > Signed-off-by: Stanimir Varbanov > > Signed-off-by: Stanimir Varbanov > > --- > > MAINTAINERS |7 + > > drivers/pci/host/Kconfig | 10 + > > drivers/pci/host/Makefile|1 + > > drivers/pci/host/pcie-qcom.c | 624 > > ++ > > 4 files changed, 642 insertions(+) > > create mode 100644 drivers/pci/host/pcie-qcom.c > > Hi Bjorn, any chance to get this merged in 4.5 ? The driver looks good overall, so I think 4.5 is very possible. It doesn't look like there's really a consensus on the memory barrier thing yet, and I assume the testing reports include that first patch, so it'd be good to get that resolved first. Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm64: dts: berlin4ct: switch to Cortex-A53 specific pmu nodes
On 15.12.2015 15:57, Jisheng Zhang wrote:
> Commit ac82d1277215 ("arm64: perf: add Cortex-A53 support") adds the
> cortex A53 PMU support, thus instead of using the generic armv8-pmuv3
> compatibility use the more specific Cortex A53 compatibility.
>
> Signed-off-by: Jisheng Zhang
> ---
> Since v1:
> - keep "arm,armv8-pmuv3" as a fallback in the compatible list. Thank
>Arnd and Mark.
Applied to berlin64/dt with an updated commit message that
reflects v2 changes.
Sebastian
> arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> index 099ad93..f926256 100644
> --- a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> +++ b/arch/arm64/boot/dts/marvell/berlin4ct.dtsi
> @@ -115,7 +115,7 @@
> };
>
> pmu {
> - compatible = "arm,armv8-pmuv3";
> + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
> interrupts = ,
>,
>,
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB: add generic onboard USB HUB driver
Hi Fabio,
Hi Peter,
On 16.12.2015 11:11, Fabio Estevam wrote:
> Hi Peter,
>
> On Wed, Dec 16, 2015 at 2:11 AM, Peter Chen wrote:
>
>> Thanks, Fabio, but I am curious how things like that? The USBOH3 clock
>> is not opened, the usb driver will hang when it tries to access
>> registers. If this clock is always on, then, why the system will
>> hang later?
>
> I found the issue with your patch. You missed to add the pinctrl node.
>
> With the change below USB is functional in Udoo:
>
> --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> @@ -22,6 +22,8 @@
>
> usb_hub1 {
> compatible = "generic-onboard-hub";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbh>;
> clocks = <&clks IMX6QDL_CLK_CKO>;
> reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> reset-duration-us = <2>;
>
Thanks for your work, I didn't notice it previously (sorry).
I can confirm, too that with Peter's patches and the above change
the USB support works again on my UDOO DualLite board.
However, I noticed that when you have host USB support configured to be
build as modules then (due to its location under "if USB") it is only
possible to compile generic onboard USB HUB as module, too.
Then this module would need to be loaded before loading USB support
(or quickly after it), otherwise USB enumeration would time out after
few secs and loading it later wouldn't help.
Currently, this driver doesn't really need any USB host support and
is able to be compiled-in successfully regardless of USB host support
configuration with just small change to Makefile and Kconfig.
However I don't know if it is a design goal to not use USB host support
or just a current development status, but if it doesn't really need it
then it would be great if it could be selected to be build-in into kernel
regardless of host USB support setting.
Best regards,
Maciej Szmigiero
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] net/macb: add support for resetting PHY using GPIO
On Wednesday 16 December 2015 19:31:30 Gregory CLEMENT wrote: > diff --git a/drivers/net/ethernet/cadence/macb.c > b/drivers/net/ethernet/cadence/macb.c > index 88c1e1a..35661aa 100644 > --- a/drivers/net/ethernet/cadence/macb.c > +++ b/drivers/net/ethernet/cadence/macb.c > @@ -28,6 +28,7 @@ > #include > #include > #include > +#include > #include > #include Is this the patch that is already in linux-next? I needed an additional #include to avoid this build error on randconfig builds without GPIOLIB: drivers/net/ethernet/cadence/macb.c: In function 'macb_probe': drivers/net/ethernet/cadence/macb.c:2908:19: error: implicit declaration of function 'devm_gpiod_get_optional' [-Werror=implicit-function-declaration] bp->reset_gpio = devm_gpiod_get_optional(&bp->pdev->dev, "phy-reset", ^ drivers/net/ethernet/cadence/macb.c:2909:8: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function) GPIOD_OUT_HIGH); ^ drivers/net/ethernet/cadence/macb.c:2909:8: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/cadence/macb.c: In function 'macb_remove': drivers/net/ethernet/cadence/macb.c:2979:3: error: implicit declaration of function 'gpiod_set_value' [-Werror=implicit-function-declaration] Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] net/macb: add support for resetting PHY using GPIO
Hi Richard,
On mer., déc. 16 2015, Richard Cochran wrote:
> On Wed, Dec 16, 2015 at 07:31:30PM +0100, Gregory CLEMENT wrote:
>> +Optional properties for PHY child node:
>> +- reset-gpios : Should specify the gpio for phy reset
>
> reset-gpios plural or reset-gpio singular?
The bindings name is plural but it handle only one gpio.
See:
https://lkml.org/lkml/2015/12/9/623
>
>> +
>> Examples:
>>
>> macb0: ethernet@fffc4000 {
>> @@ -29,4 +32,8 @@ Examples:
>> local-mac-address = [3a 0e 03 04 05 06];
>> clock-names = "pclk", "hclk", "tx_clk";
>> clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
>> +ethernet-phy@1 {
>> +reg = <0x1>;
>> +reset-gpios = <&pioE 6 1>;
>
> Did you mean "gpioE" ?
No, I really mean pioE: it is the name used for the at91 SoCs.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] net/macb: add support for resetting PHY using GPIO
On Wed, Dec 16, 2015 at 07:31:30PM +0100, Gregory CLEMENT wrote:
> +Optional properties for PHY child node:
> +- reset-gpios : Should specify the gpio for phy reset
reset-gpios plural or reset-gpio singular?
> +
> Examples:
>
> macb0: ethernet@fffc4000 {
> @@ -29,4 +32,8 @@ Examples:
> local-mac-address = [3a 0e 03 04 05 06];
> clock-names = "pclk", "hclk", "tx_clk";
> clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
> + ethernet-phy@1 {
> + reg = <0x1>;
> + reset-gpios = <&pioE 6 1>;
Did you mean "gpioE" ?
Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] devicetree: sound: add binding for WM8974 codec
On Wed, Dec 16, 2015 at 01:54:20PM +, Måns Rullgård wrote: > Mark Brown writes: > > I need the patch in a form I can apply. > I assumed your email client had some way of displaying the message I > replied to. Guess I was wrong. My workflow for reviewing and applying patches is based around my inbox, as are most review flows in the kernel - things that aren't in my inbox *might* get looked at but it's unreliable. > > You can't blindly rely on get_maintainers, it's prone to both false > > positives (CCing too many people, especially if you enable git matching > > when it often starts spamming people who are just doing global cleanups) > > and false negatives (if you don't enable git matching and it misses > > people who care about a specific driver). > So in short, I'm supposed to magically divine who wants to see what. You're supposed to do like SubmittingPatches suggests make a judgement call based on things like looking at MAINTAINERS and the people that git shows are reviewing and applying patches or otherwise seem relevant - it's not really something that can be fully automated (for example, it might make sense to CC someone who worked on the specific thing you're changing even if they don't commonly review the file as a whole). Looking at git history will also help you ensure that the style you're presenting your changes in (for example things like the subject line) matches the general style people are using. signature.asc Description: PGP signature
[RFC 1/3] i2c: document binding for multi-master case
From: Wolfram Sang We need this binding because some I2C master drivers will need to adapt their PM settings for the arbitration circuitry. I skipped the "i2c-" prefix because I can imagine to be useful outside of i2c. Signed-off-by: Wolfram Sang Cc: devicetree@vger.kernel.org --- Documentation/devicetree/bindings/i2c/i2c.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index a00219f5ee0733..c8d977ed847f3c 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -54,6 +54,11 @@ wants to support one of the below features, it should adapt the bindings below. "irq" and "wakeup" names are recognized by I2C core, other names are left to individual drivers. +- multi-master + states that there is another master active on this bus. The OS can use + this information to adapt power management to keep the arbitration awake + all the time, for example. + - wakeup-source device can be used as a wakeup source. -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] net/macb: add support for resetting PHY using GPIO
With device tree it is no more possible to reset the PHY at board
level. Furthermore, doing in the driver allow to power down the PHY when
the network interface is no more used.
This reset can't be done at the PHY driver level. The PHY must be able to
answer to the mii bus scan to let the kernel creating a PHY device.
The patch introduces a new optional property "reset-gpios" at PHY level.
Signed-off-by: Gregory CLEMENT
---
Hi,
I agree with Sasha to start with a good binding and indeed the reset
is more related to the PHY than to the MAC even if currently we have
to manipulate it at MAC level.
I also followed Russell advice to not use fwnode functions. However
the following code seems to work:
struct fwnode_handle *phy_node =
device_get_next_child_node(&pdev->dev, NULL);
bp->reset_gpio = fwnode_get_named_gpiod(phy_node, "reset-gpios");
if (IS_ERR)
bp->reset_gpio = NULL;
gpiod_set_value(bp->reset_gpio, GPIOD_OUT_HIGH);
Given that it doesn't make the code better I kept the of_get_named_gpio method.
Gregory
Documentation/devicetree/bindings/net/macb.txt | 7 +++
drivers/net/ethernet/cadence/macb.c| 16
drivers/net/ethernet/cadence/macb.h| 1 +
3 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/macb.txt
b/Documentation/devicetree/bindings/net/macb.txt
index b5d7976..38c8e84 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -19,6 +19,9 @@ Required properties:
Optional elements: 'tx_clk'
- clocks: Phandles to input clocks.
+Optional properties for PHY child node:
+- reset-gpios : Should specify the gpio for phy reset
+
Examples:
macb0: ethernet@fffc4000 {
@@ -29,4 +32,8 @@ Examples:
local-mac-address = [3a 0e 03 04 05 06];
clock-names = "pclk", "hclk", "tx_clk";
clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
+ ethernet-phy@1 {
+ reg = <0x1>;
+ reset-gpios = <&pioE 6 1>;
+ };
};
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 88c1e1a..35661aa 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2813,6 +2814,7 @@ static int macb_probe(struct platform_device *pdev)
= macb_clk_init;
int (*init)(struct platform_device *) = macb_init;
struct device_node *np = pdev->dev.of_node;
+ struct device_node *phy_node;
const struct macb_config *macb_config = NULL;
struct clk *pclk, *hclk, *tx_clk;
unsigned int queue_mask, num_queues;
@@ -2900,6 +2902,16 @@ static int macb_probe(struct platform_device *pdev)
else
macb_get_hwaddr(bp);
+ /* Power up the PHY if there is a GPIO reset */
+ phy_node = of_get_next_available_child(np, NULL);
+ if (phy_node) {
+ int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
+ if (gpio_is_valid(gpio))
+ bp->reset_gpio = gpio_to_desc(gpio);
+ gpiod_set_value(bp->reset_gpio, GPIOD_OUT_HIGH);
+ }
+ of_node_put(phy_node);
+
err = of_get_phy_mode(np);
if (err < 0) {
pdata = dev_get_platdata(&pdev->dev);
@@ -2966,6 +2978,10 @@ static int macb_remove(struct platform_device *pdev)
mdiobus_unregister(bp->mii_bus);
kfree(bp->mii_bus->irq);
mdiobus_free(bp->mii_bus);
+
+ /* Shutdown the PHY if there is a GPIO reset */
+ gpiod_set_value(bp->reset_gpio, GPIOD_OUT_LOW);
+
unregister_netdev(dev);
clk_disable_unprepare(bp->tx_clk);
clk_disable_unprepare(bp->hclk);
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 6e1faea..b6ec421 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -824,6 +824,7 @@ struct macb {
unsigned intdma_burst_length;
phy_interface_t phy_interface;
+ struct gpio_desc*reset_gpio;
/* AT91RM9200 transmit */
struct sk_buff *skb;/* holds skb until xmit
interrupt completes */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] ARM: dts: imx6q-icore-rqs: Add Engicam IMX6 Q7 initial support
Hi
I have address most of the changes but I have problem when I remove
the group of pinctrl as you suggest
On Mon, Dec 14, 2015 at 09:44:56AM +0100, Michael Trimarchi wrote:
> Hi
>
> On Fri, Dec 11, 2015 at 04:36:17PM +0800, Shawn Guo wrote:
> > On Wed, Nov 18, 2015 at 04:10:34PM +0100, Michael Trimarchi wrote:
> > > www.engicam.com/en/products/embedded/som/standard/i-core-rqs-m6s-dl-d-q
> > >
> > > Signed-off-by: Michael Trimarchi
> > > ---
> > > I'm not quite sure how ethernet tuning parameter
> > > are working in other setup and this seems the
> > > correct way to use it
> > >
> > > Changes in v3:
> > > - add sgtl audio support
> > > - add ethernet gigabit tuning
> > > - use hub reset only in usbhub and not
> > > in otg vbus
> > >
> > > Changes in v2:
> > > - add the board in alphabetic order
> > > - remove cpu operating point
> > > - remove simple-bus and adjust regulaotor
> > > - add gpios to correct pinctrl
> > > - remove no mainline binding of gpc
> > >
> > > arch/arm/boot/dts/Makefile | 1 +
> > > arch/arm/boot/dts/imx6q-icore-rqs.dts| 45
> > > arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi | 382
> > > +++
> > > 3 files changed, 428 insertions(+)
> > > create mode 100644 arch/arm/boot/dts/imx6q-icore-rqs.dts
> > > create mode 100644 arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> > >
> > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > > index bb8fa02..7e8f29c 100644
> > > --- a/arch/arm/boot/dts/Makefile
> > > +++ b/arch/arm/boot/dts/Makefile
> > > @@ -312,6 +312,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > > imx6q-gw551x.dtb \
> > > imx6q-gw552x.dtb \
> > > imx6q-hummingboard.dtb \
> > > + imx6q-icore-rqs.dtb \
> > > imx6q-nitrogen6x.dtb \
> > > imx6q-phytec-pbab01.dtb \
> > > imx6q-rex-pro.dtb \
> > > diff --git a/arch/arm/boot/dts/imx6q-icore-rqs.dts
> > > b/arch/arm/boot/dts/imx6q-icore-rqs.dts
> > > new file mode 100644
> > > index 000..8f14edf
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/imx6q-icore-rqs.dts
> > > @@ -0,0 +1,45 @@
> > > +/*
> > > + * Copyright (C) 2015 Amarula Solutions B.V.
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + */
> >
> > Suggest to use GPL/X11 dual licences, so that non-Linux can use it too.
> > You can find a lot of examples in arch/arm/boot/dts.
> >
>
> Ok
>
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "imx6q.dtsi"
> > > +#include "imx6qdl-icore-rqs.dtsi"
> > > +
> > > +/ {
> > > + model = "Engicam i.CoreM6 Quad SOM";
> > > + compatible = "fsl,imx6-icore-rqs", "fsl,imx6q";
> >
> > This is not a board from Freescale, so 'fsl,' is not a appropriate for
> > the board compatible imx6q-icore-rqs.
> >
>
> let use eng,imx6-icore-rqs
>
That I have fixed
> > > +
> > > + sound {
> > > + compatible = "fsl,imx-audio-sgtl5000";
> > > + model = "imx-audio-sgtl5000";
> > > + ssi-controller = <&ssi1>;
> > > + audio-codec = <&codec>;
> > > + audio-routing =
> > > + "MIC_IN", "Mic Jack",
> > > + "Mic Jack", "Mic Bias",
> > > + "Headphone Jack", "HP_OUT";
> > > + mux-int-port = <1>;
> > > + mux-ext-port = <4>;
> > > + };
> > > +};
> > > +
> > > +&sata {
> > > + status = "okay";
> > > +};
> >
> > Please sort them labelled nodes alphabetically.
> >
>
> ok
>
You mean sata and i2c?
> > > +
> > > +&i2c3 {
> > > + codec: sgtl5000@0a {
> > > + compatible = "fsl,sgtl5000";
> > > + reg = <0x0a>;
> > > + clocks = <&clks IMX6QDL_CLK_CKO>;
> > > + VDDA-supply = <®_2p5v>;
> > > + VDDIO-supply = <®_3p3v>;
> > > + VDDD-supply = <®_1p8v>;
> > > + };
> > > +};
> > > diff --git a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> > > b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> > > new file mode 100644
> > > index 000..c57a830
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> > > @@ -0,0 +1,382 @@
> > > +/*
> > > + * Copyright 2015 Amarula Solutions B.V.
> > > + *
> > > + * The code contained herein is licensed under the GNU General Public
> > > + * License. You may obtain a copy of the GNU General Public License
> > > + * Version 2 or later at the following locations:
> > > + *
> > > + * http://www.opensource.org/licenses/gpl-license.html
> > > + * http://www.gnu.org/copyleft/gpl.html
> > > + */
> > > +#include
> > > +#include
> > > +
> > > +/ {
> > > + memory {
> > > + reg = <0x1000 0x8000>;
> > > + };
> > > +
> > > + reg_1p8v: 1p8v {
> >
> > Can we name these regulator nodes a bit better, something like
> > 'regulator-1pv8'?
> >
>
> ok
>
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "1P8V";
> > > + regulator-min-microvolt = <180>;
> > > +
[PATCH v3] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
---
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 153
4 files changed, 183 insertions(+)
Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
+ };
Index: renesas/drivers/extcon/Kconfig
===
--- renesas.orig/drivers/extcon/Kconfig
+++ renesas/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: renesas/drivers/extcon/Makefile
===
--- renesas.orig/drivers/extcon/Makefile
+++ renesas/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
Index: renesas/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ renesas/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,153 @@
+/*
+ * Maxim Integrated MAX3355 USB OTG chip extcon driver
+ *
+ * Copyright (C) 2014 Cogent Embedded, Inc.
+ * Author: Sergei Shtylyov
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied
Re: [PATCH RESEND v3 0/9] Add STM32 pinctrl/GPIO driver
Hi Maxime You can add my Acked-by after fixing the patch 4/9 Thanks Patrice On 12/11/2015 09:24 AM, Maxime Coquelin wrote: Hi Linus, Patrice, I resend the series for Patrice to review it. Thanks, Maxime This is the third round of STM32 pinctrl series, which improves DT bindings declaration and documentation, and also fixes some commit fixup issues. The series also contains two more patches, adding GPIO LEDs support as a user of this driver. The STM32 family has 16 pins per GPIO bank, and the number of bank varies depending on the model. Pins can be multiplexed either in GPIO mode, alternate function (up to 15 functions per pin) or analog (for ADC/DAC). Changes since v2: - - Rebase on v4.4-rc1 - Declare leds also for Eval board - Set green led as heartbeat - Collect some acks Changes since v1: - - Add GPIO LEDs support in DT and defconfig - Changes pinmux DT bindings from macros to raw values (Daniel) - Improve DT bindings documentation (Daniel) - Fix some commit fixup and rebase issues. Kind regards, Maxime Maxime Coquelin (9): ARM: Kconfig: Introduce MACH_STM32F429 flag Documentation: dt-bindings: Document STM32 pinctrl driver DT bindings includes: dt-bindings: Add STM32F429 pinctrl DT bindings pinctrl: Add STM32 MCUs support ARM: mach-stm32: Select pinctrl ARM: dts: Add pinctrl node to STM32F429 ARM: dts: Add USART1 pin config to STM32F429 boards ARM: dts: Add leds support to STM32F429 boards ARM: config: Enable GPIO Led driver in stm32_defconfig .../bindings/pinctrl/st,stm32-pinctrl.txt | 126 ++ arch/arm/Kconfig |6 + arch/arm/boot/dts/stm32429i-eval.dts | 19 + arch/arm/boot/dts/stm32f429-disco.dts | 13 + arch/arm/boot/dts/stm32f429.dtsi | 110 ++ arch/arm/configs/stm32_defconfig |1 + drivers/pinctrl/Kconfig|1 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/stm32/Kconfig | 16 + drivers/pinctrl/stm32/Makefile |5 + drivers/pinctrl/stm32/pinctrl-stm32.c | 856 +++ drivers/pinctrl/stm32/pinctrl-stm32.h | 43 + drivers/pinctrl/stm32/pinctrl-stm32f429.c | 1598 include/dt-bindings/pinctrl/pinctrl-stm32.h| 12 + include/dt-bindings/pinctrl/stm32f429-pinfunc.h| 1241 +++ 15 files changed, 4048 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt create mode 100644 drivers/pinctrl/stm32/Kconfig create mode 100644 drivers/pinctrl/stm32/Makefile create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c create mode 100644 include/dt-bindings/pinctrl/pinctrl-stm32.h create mode 100644 include/dt-bindings/pinctrl/stm32f429-pinfunc.h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/9] pinctrl: Add STM32 MCUs support
Hi Maxime
On 12/11/2015 09:25 AM, Maxime Coquelin wrote:
This patch adds pinctrl and GPIO support to STMicroelectronic's STM32
family of MCUs.
While it only supports STM32F429 for now, it has been designed to enable
support of other MCUs of the family (e.g. STM32F746).
Signed-off-by: Maxime Coquelin
---
drivers/pinctrl/Kconfig |1 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/stm32/Kconfig | 16 +
drivers/pinctrl/stm32/Makefile|5 +
drivers/pinctrl/stm32/pinctrl-stm32.c | 856 +++
drivers/pinctrl/stm32/pinctrl-stm32.h | 43 +
drivers/pinctrl/stm32/pinctrl-stm32f429.c | 1598 +
7 files changed, 2520 insertions(+)
create mode 100644 drivers/pinctrl/stm32/Kconfig
create mode 100644 drivers/pinctrl/stm32/Makefile
create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.c
create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32.h
create mode 100644 drivers/pinctrl/stm32/pinctrl-stm32f429.c
[...]
+
+static int stm32_pctrl_dt_subnode_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *node,
+ struct pinctrl_map **map,
+ unsigned *reserved_maps,
+ unsigned *num_maps)
+{
+ struct stm32_pinctrl *pctl;
+ struct stm32_pinctrl_group *grp;
+ struct property *pins;
+ u32 pinfunc, pin, func;
+ unsigned long *configs;
+ unsigned int num_configs;
+ bool has_config = 0;
+ unsigned reserve = 0;
+ int num_pins, num_funcs, maps_per_pin, i, err;
+
+ pctl = pinctrl_dev_get_drvdata(pctldev);
+
+ pins = of_find_property(node, "pinmux", NULL);
+ if (!pins) {
+ dev_err(pctl->dev, "missing pins property in node %s .\n",
+ node->name);
+ return -EINVAL;
+ }
+
+ err = pinconf_generic_parse_dt_config(node, pctldev, &configs,
+ &num_configs);
+ if (num_configs)
+ has_config = 1;
+
+ num_pins = pins->length / sizeof(u32);
+ num_funcs = num_pins;
+ maps_per_pin = 0;
+ if (num_funcs)
+ maps_per_pin++;
+ if (has_config && num_pins >= 1)
+ maps_per_pin++;
+
+ if (!num_pins || !maps_per_pin)
+ return -EINVAL;
+
+ reserve = num_pins * maps_per_pin;
+
+ err = pinctrl_utils_reserve_map(pctldev, map,
+ reserved_maps, num_maps, reserve);
+ if (err < 0)
+ goto fail;
+
+ for (i = 0; i < num_pins; i++) {
+ err = of_property_read_u32_index(node, "pinmux",
+ i, &pinfunc);
+ if (err)
+ goto fail;
as a "goto fail" doesn't do more than a return, here do directly "return
err;"
+
+ pin = STM32_GET_PIN_NO(pinfunc);
+ func = STM32_GET_PIN_FUNC(pinfunc);
+
+ if (pin >= pctl->match_data->npins) {
+ dev_err(pctl->dev, "invalid pin number.\n");
+ err = -EINVAL;
+ goto fail;
ditto, return -EINVAL
+ }
+
+ if (!stm32_pctrl_is_function_valid(pctl, pin, func)) {
+ dev_err(pctl->dev, "invalid function.\n");
+ err = -EINVAL;
+ goto fail;
ditto
+ }
+
+ grp = stm32_pctrl_find_group_by_pin(pctl, pin);
+ if (!grp) {
+ dev_err(pctl->dev, "unable to match pin %d to group\n",
+ pin);
+ return -EINVAL;
+ }
+
+ err = stm32_pctrl_dt_node_to_map_func(pctl, pin, func, grp, map,
+ reserved_maps, num_maps);
+ if (err < 0)
+ goto fail;
ditto
+
+ if (has_config) {
+ err = pinctrl_utils_add_map_configs(pctldev, map,
+ reserved_maps, num_maps, grp->name,
+ configs, num_configs,
+ PIN_MAP_TYPE_CONFIGS_GROUP);
+ if (err < 0)
+ goto fail;
ditto
+ }
+ }
+
+ return 0;
+
+fail:
+ return err;
+}
+
[...]
+
+static int stm32_pmx_set_mux(struct pinctrl_dev *pctldev,
+ unsigned function,
+ unsigned group)
+{
+ bool ret;
+ const struct stm32_desc_function *desc;
+ struct stm32_pinctrl *pctl = pinctrl_dev_get_drvdata(pctldev);
+ struct stm32_pinctrl_group *g = pctl->groups + group;
+ struct pinctrl_gpio_range *range;
+ struct stm32_gpio_bank *bank;
+ u32 mode
[PATCH resend] pinctrl: sunxi: Add A80 special pin controller
From: Maxime Ripard
Like the previous designs, the A80 has a special pin controller for the
critical pins, like the PMIC bus.
Add a driver for this controller.
Signed-off-by: Maxime Ripard
[wens: Add A80 compatible strings to bindings doc; fix pin function
names based on v1.3 datasheet; constify of_device_id table]
Signed-off-by: Chen-Yu Tsai
Acked-by: Rob Herring
---
Linus, can we have this one included for 4.5?
Thanks
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 2 +
drivers/pinctrl/sunxi/Kconfig | 5 +
drivers/pinctrl/sunxi/Makefile | 1 +
drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c| 181 +
4 files changed, 189 insertions(+)
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index b321b26780dc..b3b6c2f210d7 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -18,6 +18,8 @@ Required properties:
"allwinner,sun8i-a23-r-pinctrl"
"allwinner,sun8i-a33-pinctrl"
"allwinner,sun8i-a83t-pinctrl"
+ "allwinner,sun9i-a80-pinctrl"
+ "allwinner,sun9i-a80-r-pinctrl"
- reg: Should contain the register physical address and length for the
pin controller.
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index e68fd951129a..0252b3fa41ce 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -55,4 +55,9 @@ config PINCTRL_SUN9I_A80
def_bool MACH_SUN9I
select PINCTRL_SUNXI_COMMON
+config PINCTRL_SUN9I_A80_R
+ def_bool MACH_SUN9I
+ depends on RESET_CONTROLLER
+ select PINCTRL_SUNXI_COMMON
+
endif
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index e08029034510..0b4b827f314b 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
+obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
new file mode 100644
index ..42547ffa20a8
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c
@@ -0,0 +1,181 @@
+/*
+ * Allwinner A80 SoCs special pins pinctrl driver.
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ * Maxime Ripard
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun9i_a80_r_pins[] = {
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_uart"),/* TX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PL_EINT0 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_uart"),/* RX */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PL_EINT1 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag"),/* TMS */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* PL_EINT2 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag"),/* TCK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* PL_EINT3 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag"),/* TDO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)), /* PL_EINT4 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag"),/* TDI */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)), /* PL_EINT5 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI
[PATCH v6 0/9] mfd: axp20x: Add support for RSB based AXP223
Hi everyone, This is v6 of the AXP223 PMIC series. v6 fixes the address of the AXP223 in the DT. Hope this series makes it into 4.5, and we can then support even more AXP PMICs in 4.6+. Lee, can you take the first 7 patches. Once they're in, Maxime can take the DTS patches. Changes since v5: - Correct AXP223 address to 0x3a3. Changes since v4: - Get rid of second parameter of axp20x_match_device() (new patch 2) - Match against dev->driver->of_match_table, so the entirety of axp20x_match_device() can be kept in the core. (new patch 3) - Move *_device_id tables to bottom of the driver, right above driver declaration. (patch 4 & 6) - Remove extra whitespaces while moving i2c specific code (patch 4) - Remove leftover whitespace and code style issues in axp20x core (new patch 5) - Remove extra whitespaces in rsb specific code (patch 6) Changes since v3: - Removed settings for axp223 reg_rtc_ldo from board dts files that are already in axp22x.dtsi. The name is kept. - Dropped simplefb label and defconfig patches, as they are merged. Changes since v2: - s/It's/Its/ for the commit messages of patches 5 and 7 - Add Rob's Acked-by for patch 1 Changes since v1: - Dropped NMI interrupt controller dts patch (Merged) - Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE - Keep the axp20x core bits named axp20x.c - Add patch 7 to add AXP223 to sun8i-q8-common.dtsi - Add patch 8 & 9 to update defconfigs - Make axp20x drivers tristate and buildable as modules - Drop "_sunxi" substring from identifiers in axp20x-rsb driver This series adds support for the Reduced Serial Bus based AXP223 PMIC. The AXP223 is functionally identical to the AXP221, which we already support. Only some default values for the regulators are different. The defaults fit their recommended application, paired with different SoCs. Patch 1 adds AXP223 to the list of supported chips in the DT binding. Patch 2 gets rid of the extra "struct device *" parameter from axp20x_match_device(). Patch 3 makes axp20x_match_device() use dev->driver->of_match_table, so the function can be library-ized without modification. Patch 4 splits the axp20x mfd driver into 2 parts, a core library, and an I2C driver. Patch 5 cleans up some leftover whitespace issues in axp20x core. Patch 6 adds an RSB based driver for the AXP223. Patch 7 adds support for the AXP223 regulators Patch 8 enables the AXP223 PMIC and its regulators for the Sinlinx SinA33. Patch 9 enables the AXP223 PMIC and its regulators for A23/A33 based Q8 tablet devices. Regards ChenYu Chen-Yu Tsai (9): mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings mfd: axp20x: Remove second struct device * parameter for axp20x_match_device() mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device() mfd: axp20x: Split the driver into core and i2c bits mfd: axp20x: Whitespace, open parenthesis alignment code style fixes mfd: axp20x: Add support for RSB based AXP223 PMIC regulator: axp20x: Support new AXP223 PMIC ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes Documentation/devicetree/bindings/mfd/axp20x.txt | 7 +- arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 - arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +- drivers/mfd/Kconfig | 25 -- drivers/mfd/Makefile | 2 + drivers/mfd/axp20x-i2c.c | 102 +++ drivers/mfd/axp20x-rsb.c | 78 + drivers/mfd/axp20x.c | 101 +- drivers/regulator/axp20x-regulator.c | 3 + include/linux/mfd/axp20x.h | 34 +++- 10 files changed, 418 insertions(+), 93 deletions(-) create mode 100644 drivers/mfd/axp20x-i2c.c create mode 100644 drivers/mfd/axp20x-rsb.c -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/9] mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()
In axp20x_match_device(), match the of_device_id table bound to the
device driver instead of pointing to axp20x_of_match directly. This
will allow us to keep axp20x_match_device() unmodified when we expand
the axp20x driver into multiple ones covering different interface
types.
of_device_get_match_data() cannot be used here as we need to know if
it failed to get a match, or if the match data value just happened to
be 0, as it is for the AXP152.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 685a78614f83..3e186f2dcac3 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -613,7 +613,7 @@ static int axp20x_match_device(struct axp20x_dev *axp20x)
const struct of_device_id *of_id;
if (dev->of_node) {
- of_id = of_match_device(axp20x_of_match, dev);
+ of_id = of_match_device(dev->driver->of_match_table, dev);
if (!of_id) {
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/9] mfd: axp20x: Split the driver into core and i2c bits
The axp20x driver assumes the device is i2c based. This is not the
case with later chips, which use a proprietary 2 wire serial bus
by Allwinner called "Reduced Serial Bus".
This patch follows the example of mfd/wm831x and splits it into
an interface independent core, and an i2c specific glue layer.
MFD_AXP20X and the new MFD_AXP20X_I2C are changed to tristate
symbols, allowing the driver to be built as modules.
Whitespace and other style errors in the moved i2c specific code
have been fixed. Included but unused header files are removed as
well.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/Kconfig| 14 ---
drivers/mfd/Makefile | 1 +
drivers/mfd/axp20x-i2c.c | 102 +
drivers/mfd/axp20x.c | 88 +++---
include/linux/mfd/axp20x.h | 33 ++-
5 files changed, 158 insertions(+), 80 deletions(-)
create mode 100644 drivers/mfd/axp20x-i2c.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6ef9fe..804cd3dcce32 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -91,14 +91,18 @@ config MFD_BCM590XX
Support for the BCM590xx PMUs from Broadcom
config MFD_AXP20X
- bool "X-Powers AXP20X"
+ tristate
select MFD_CORE
- select REGMAP_I2C
select REGMAP_IRQ
- depends on I2C=y
+
+config MFD_AXP20X_I2C
+ tristate "X-Powers AXP series PMICs with I2C"
+ select MFD_AXP20X
+ select REGMAP_I2C
+ depends on I2C
help
- If you say Y here you get support for the X-Powers AXP202, AXP209 and
- AXP288 power management IC (PMIC).
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with I2C.
This driver include only the core APIs. You have to select individual
components like regulators or the PEK (Power Enable Key) under the
corresponding menus.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a8b76b81b467..a6913007d667 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
obj-$(CONFIG_MFD_AXP20X) += axp20x.o
+obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
obj-$(CONFIG_MFD_LP3943) += lp3943.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
new file mode 100644
index ..b54205677bb2
--- /dev/null
+++ b/drivers/mfd/axp20x-i2c.c
@@ -0,0 +1,102 @@
+/*
+ * axp20x-i2c.c - I2C driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the I2C variants.
+ *
+ * Author: Carlo Caione
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int axp20x_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
+ struct axp20x_dev *axp20x;
+ int ret;
+
+ axp20x = devm_kzalloc(&i2c->dev, sizeof(*axp20x), GFP_KERNEL);
+ if (!axp20x)
+ return -ENOMEM;
+
+ axp20x->dev = &i2c->dev;
+ axp20x->irq = i2c->irq;
+ dev_set_drvdata(axp20x->dev, axp20x);
+
+ ret = axp20x_match_device(axp20x);
+ if (ret)
+ return ret;
+
+ axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
+ if (IS_ERR(axp20x->regmap)) {
+ ret = PTR_ERR(axp20x->regmap);
+ dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
+ return ret;
+ }
+
+ return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_i2c_remove(struct i2c_client *i2c)
+{
+ struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
+
+ return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_i2c_of_match[] = {
+ { .compatible = "x-powers,axp152", .data = (void *)AXP152_ID },
+ { .compatible = "x-powers,axp202", .data = (void *)AXP202_ID },
+ { .compatible = "x-powers,axp209", .data = (void *)AXP209_ID },
+ { .compatible = "x-powers,axp221", .data = (void *)AXP221_ID },
+ { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
+
+/*
+ * This is useless for OF-enabled devices, but it is needed by I2C subsystem
+ */
+static const struct i2c_device_id axp20x_i2c_id[] = {
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
+
+static const struct acpi_device_id axp20x_i2c_acpi_match[] = {
+ {
+
[PATCH v6 2/9] mfd: axp20x: Remove second struct device * parameter for axp20x_match_device()
The first argument passed to axp20x_match_device(), struct axp20x_dev *,
already contains a pointer to the device. By rearranging some code,
moving the assignment of the pointer before axp20x_match_device() is
called, we can eliminate the second parameter.
Suggested-by: Andy Shevchenko
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 9842199e2e6c..685a78614f83 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -606,8 +606,9 @@ static void axp20x_power_off(void)
AXP20X_OFF);
}
-static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
+static int axp20x_match_device(struct axp20x_dev *axp20x)
{
+ struct device *dev = axp20x->dev;
const struct acpi_device_id *acpi_id;
const struct of_device_id *of_id;
@@ -673,14 +674,14 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
if (!axp20x)
return -ENOMEM;
- ret = axp20x_match_device(axp20x, &i2c->dev);
- if (ret)
- return ret;
-
axp20x->i2c_client = i2c;
axp20x->dev = &i2c->dev;
dev_set_drvdata(axp20x->dev, axp20x);
+ ret = axp20x_match_device(axp20x);
+ if (ret)
+ return ret;
+
axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
if (IS_ERR(axp20x->regmap)) {
ret = PTR_ERR(axp20x->regmap);
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/9] mfd: axp20x: Whitespace, open parenthesis alignment code style fixes
This fixes some leftover code style issues in the axp20x core.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 631ad64ddf69..54a00168da26 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -591,14 +591,14 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
}
- axp20x->variant = (long) of_id->data;
+ axp20x->variant = (long)of_id->data;
} else {
acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
if (!acpi_id || !acpi_id->driver_data) {
dev_err(dev, "Unable to match ACPI ID and data\n");
return -ENODEV;
}
- axp20x->variant = (long) acpi_id->driver_data;
+ axp20x->variant = (long)acpi_id->driver_data;
}
switch (axp20x->variant) {
@@ -632,7 +632,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
return -EINVAL;
}
dev_info(dev, "AXP20x variant %s found\n",
- axp20x_model_names[axp20x->variant]);
+axp20x_model_names[axp20x->variant]);
return 0;
}
@@ -652,7 +652,7 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
}
ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
- axp20x->nr_cells, NULL, 0, NULL);
+ axp20x->nr_cells, NULL, 0, NULL);
if (ret) {
dev_err(axp20x->dev, "failed to add MFD devices: %d\n", ret);
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 7/9] regulator: axp20x: Support new AXP223 PMIC
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs. It is functionally identical to AXP221; only the regulator default voltage/status and the external host interface are different. Signed-off-by: Chen-Yu Tsai Reviewed-by: Mark Brown --- drivers/regulator/axp20x-regulator.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/regulator/axp20x-regulator.c b/drivers/regulator/axp20x-regulator.c index 35de22fdb7a0..55cce8125716 100644 --- a/drivers/regulator/axp20x-regulator.c +++ b/drivers/regulator/axp20x-regulator.c @@ -244,6 +244,7 @@ static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq) step = 75; break; case AXP221_ID: + case AXP223_ID: min = 1800; max = 4050; def = 3000; @@ -322,6 +323,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev *rdev, int id, u32 work break; case AXP221_ID: + case AXP223_ID: if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5) return -EINVAL; @@ -360,6 +362,7 @@ static int axp20x_regulator_probe(struct platform_device *pdev) nregulators = AXP20X_REG_ID_MAX; break; case AXP221_ID: + case AXP223_ID: regulators = axp22x_regulators; nregulators = AXP22X_REG_ID_MAX; break; -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 9/9] ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes
A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. Its
regulators provide power to various parts of the SoC and the board.
Also add lcd regulator supply for simplefb and update the existing
vmmc-supply for mmc0.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +-
1 file changed, 81 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi
b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 1a69231d2da5..9d2b7e2f5975 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -56,7 +56,6 @@
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
default-brightness-level = <8>;
enable-gpios = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
- /* backlight is powered by AXP223 DC1SW */
};
chosen {
@@ -67,7 +66,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_q8>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <®_dcdc1>;
bus-width = <4>;
cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -92,6 +91,82 @@
&r_rsb {
status = "okay";
+
+ axp22x: pmic@3a3 {
+ compatible = "x-powers,axp223";
+ reg = <0x3a3>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <®_dcdc1>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+®_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-io";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <235>;
+ regulator-max-microvolt = <265>;
+ regulator-name = "vdd-dll";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dc1sw {
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-lcd";
+};
+
+®_dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpus";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-sys";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
};
&r_uart {
@@ -99,3 +174,7 @@
pinctrl-0 = <&r_uart_pins_a>;
status = "okay";
};
+
+&simplefb_lcd {
+ vcc-lcd-supply = <®_dc1sw>;
+};
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 8/9] ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes
This board has a X-Powers AXP223 PMIC connected via RSB. Its regulators
provide power to various parts of the SoC and the board.
Also update the regulator supply phandles.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 +-
1 file changed, 73 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 13ce68f06dd6..8af38a9719ca 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -68,7 +68,7 @@
};
&lradc {
- vref-supply = <®_vcc3v0>;
+ vref-supply = <®_dcdc1>;
status = "okay";
button@200 {
@@ -96,7 +96,7 @@
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_sina33>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <®_dcdc1>;
bus-width = <4>;
cd-gpios = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -106,7 +106,7 @@
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_8bit_pins>;
- vmmc-supply = <®_vcc3v0>;
+ vmmc-supply = <®_dcdc1>;
bus-width = <8>;
non-removable;
status = "okay";
@@ -132,6 +132,76 @@
&r_rsb {
status = "okay";
+
+ axp22x: pmic@3a3 {
+ compatible = "x-powers,axp223";
+ reg = <0x3a3>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ eldoin-supply = <®_dcdc1>;
+ };
+};
+
+#include "axp22x.dtsi"
+
+®_aldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-io";
+};
+
+®_aldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <235>;
+ regulator-max-microvolt = <265>;
+ regulator-name = "vdd-dll";
+};
+
+®_aldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-pll-avcc";
+};
+
+®_dc5ldo {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpus";
+};
+
+®_dcdc1 {
+ regulator-always-on;
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ regulator-name = "vcc-3v0";
+};
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-sys";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <140>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc5 {
+ regulator-always-on;
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <150>;
+ regulator-name = "vcc-dram";
+};
+
+®_rtc_ldo {
+ regulator-name = "vcc-rtc";
};
&uart0 {
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/9] mfd: axp20x: Add support for RSB based AXP223 PMIC
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/Kconfig| 11 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/axp20x-rsb.c | 78 ++
drivers/mfd/axp20x.c | 2 ++
include/linux/mfd/axp20x.h | 1 +
5 files changed, 93 insertions(+)
create mode 100644 drivers/mfd/axp20x-rsb.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 804cd3dcce32..13c565103e96 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -107,6 +107,17 @@ config MFD_AXP20X_I2C
components like regulators or the PEK (Power Enable Key) under the
corresponding menus.
+config MFD_AXP20X_RSB
+ tristate "X-Powers AXP series PMICs with RSB"
+ select MFD_AXP20X
+ depends on SUNXI_RSB
+ help
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with RSB.
+ This driver include only the core APIs. You have to select individual
+ components like regulators or the PEK (Power Enable Key) under the
+ corresponding menus.
+
config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a6913007d667..caea6637d5e8 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)+= da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
obj-$(CONFIG_MFD_AXP20X) += axp20x.o
obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
+obj-$(CONFIG_MFD_AXP20X_RSB) += axp20x-rsb.o
obj-$(CONFIG_MFD_LP3943) += lp3943.o
obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
new file mode 100644
index ..76ff02b96df0
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,78 @@
+/*
+ * axp20x-rsb.c - RSB driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the RSB variants.
+ *
+ * Author: Chen-Yu Tsai
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int axp20x_rsb_probe(struct sunxi_rsb_device *rdev)
+{
+ struct axp20x_dev *axp20x;
+ int ret;
+
+ axp20x = devm_kzalloc(&rdev->dev, sizeof(*axp20x), GFP_KERNEL);
+ if (!axp20x)
+ return -ENOMEM;
+
+ axp20x->dev = &rdev->dev;
+ axp20x->irq = rdev->irq;
+ sunxi_rsb_device_set_drvdata(rdev, axp20x);
+
+ ret = axp20x_match_device(axp20x);
+ if (ret)
+ return ret;
+
+ axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev, axp20x->regmap_cfg);
+ if (IS_ERR(axp20x->regmap)) {
+ ret = PTR_ERR(axp20x->regmap);
+ dev_err(&rdev->dev, "regmap init failed: %d\n", ret);
+ return ret;
+ }
+
+ return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+ struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+ return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_rsb_of_match[] = {
+ { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+ { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
+
+static struct sunxi_rsb_driver axp20x_rsb_driver = {
+ .driver = {
+ .name = "axp20x-rsb",
+ .of_match_table = of_match_ptr(axp20x_rsb_of_match),
+ },
+ .probe = axp20x_rsb_probe,
+ .remove = axp20x_rsb_remove,
+};
+module_sunxi_rsb_driver(axp20x_rsb_driver);
+
+MODULE_DESCRIPTION("PMIC MFD sunXi RSB driver for AXP20X");
+MODULE_AUTHOR("Chen-Yu Tsai ");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 54a00168da26..968d77fb95d8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -33,6 +33,7 @@ static const char * const axp20x_model_names[] = {
"AXP202",
"AXP209",
"AXP221",
+ "AXP223",
"AXP288",
};
@@ -616,6 +617,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
break;
case AXP221_ID:
+ case AXP223_ID:
axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
axp20x->cells = axp22x_cells;
axp20x->reg
[PATCH v6 1/9] mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs. It is functionally identical to AXP221; only the regulator default voltage/status and the external host interface are different. Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Acked-by: Rob Herring Acked-by: Lee Jones --- Documentation/devicetree/bindings/mfd/axp20x.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index a474359dd206..fd39fa54571b 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -5,11 +5,12 @@ axp152 (X-Powers) axp202 (X-Powers) axp209 (X-Powers) axp221 (X-Powers) +axp223 (X-Powers) Required properties: - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209", - "x-powers,axp221" -- reg: The I2C slave address for the AXP chip + "x-powers,axp221", "x-powers,axp223" +- reg: The I2C slave address or RSB hardware address for the AXP chip - interrupt-parent: The parent interrupt controller - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin - interrupt-controller: The PMIC has its own internal IRQs @@ -51,7 +52,7 @@ LDO3 : LDO : ldo3in-supply LDO4 : LDO : ldo24in-supply: shared supply LDO5 : LDO : ldo5in-supply -AXP221 regulators, type, and corresponding input supply names: +AXP221/AXP223 regulators, type, and corresponding input supply names: RegulatorTypeSupply Name Notes ---- - -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dt-bindings: GPIO: Add generic serializer binding
On Mon, Dec 14, 2015 at 5:19 PM, Andrew F. Davis wrote: > On 12/14/2015 04:36 PM, Rob Herring wrote: >> >> On Mon, Dec 14, 2015 at 10:41 AM, Andrew F. Davis wrote: >>> >>> On 12/11/2015 03:48 PM, Linus Walleij wrote: On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis wrote: [...] > + - compatible : Should be "pisosr-gpio". I think it should also define compatible strings on the "vendor,device" format apart from the generic compatible. Sooner or later we may need to differentiate them and then that comes in handy. >>> >>> Would it be better to wait until/if this issue arises? This driver >>> targets the generic features, as these parts are very generic and >>> have been produced by many companies since the 70s I'm not sure >>> if privileging any of them makes much sense. >>> >>> What I'm worried about looks to have happened with the gpio-74x164 >>> driver, this is kind of the companion device to mine (74164 / 74165) >>> and should work with any 74164 compatible shift register (possibly 100s >>> of versions of them), but the compatible string that was added is >>> "fairchild,74hc595", a relatively new device by a single manufacturer. >>> The problem this has is then that boards will use this compatible string >>> even if the parts are not actually the Fairchild version, just to get >>> the match, when they should be using a generic string. >> >> >> I agree the generic version is fine (or find who made the first part >> ;)). What "pisosr" is is not very obvious though. Having 74165 in the >> compatible would make it somewhat more obvious it is a standard logic >> part. >> > > A quick search shows shift-registers being made from vacuum tubes for > the Colossus! Those might work with this driver if you could match the > voltage to an SPI bus... :) > > I agree about the name not being very good, but I'm not sure about > 74165 ether as it is also just a single part number. The idea was to > have a non-part number compatible string for any shift-register you > can hook to the SPI line. That way when we have boards with a sn65x882 > or something we wont have to call it a 74165. But I guess that's why > it's a "compatible:" string, and not "is-a:" string. If there are a couple then I think it is okay. If there are 10s then maybe not. Perhaps logic-pisosr or discrete-pisosr? > +Optional properties: > + - ngpios : Number of GPIO lines, default is 8. If you didn't do "pisosr-gpio" but instead "foo,sn74165", maybe you don't need to have this in the device tree but instead it can be determined from the compatible string? In that case do that. >>> >>> These devices can be daisy-chained together, so three 8bit registers >>> look exactly like one 24bit register. The only way to know this is >>> from the physical wiring of the board, not from the part number. >> >> >> Then you should say it must be multiple of 8 (or are there other >> lengths?). >> > > Some are 4bit, you can even just hook a single flip-flop to the SPI bus for > a single bit (or multiples) of input. One would hope you would just connect the CS signal directly to that input for 1-bit... I guess you could be out of GPIOs and only have a free output only CS signal. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] usb: renesas_usbhs: More compat strings
Hi, Simon Horman writes: > Hi, > > this short series adds generic, and soc-specific r8a7792 and r8a7793 compat > strings to the Renesas USBHS driver. The intention is to provide a complete > set of compat strings for known R-Car SoCs. > > Changes since v2: > * Split documentation of SoC names into separate patch > * Use correct fallback compatibility string in example > > Changes since v1: > * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than > a single compatibility string for all of R-Car. > > Simon Horman (3): > usb: renesas_usbhs: add SoC names to compatibility string > documentation > usb: renesas_usbhs: add fallback compatibility strings > usb: renesas_usbhs: add device tree support for r8a779[23] since patch 2 got a few comments, I'll wait a new series. While resending, please collect all Acks to ease my life a bit ;-) cheers -- balbi signature.asc Description: PGP signature
Re: [PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
Hi Philipp,
On Wed, Dec 16, 2015 at 5:52 PM, Philipp Zabel wrote:
> Hi Daniel,
>
> Am Dienstag, den 15.12.2015, 02:57 +0800 schrieb Daniel Kurtz:
>> HI Philipp,
>>
>> This driver is looking really good.
>>
>> But, still some things to think about (mostly small) inline below...
>
> Most of my answers below seem to be "ok" or some form thereof, but I
> have one or two questions regarding the layer_config and crtc_reset
> suggestions.
Answers to your questions below...
>
> [...]
>> > +static void mtk_ovl_layer_config(void __iomem *ovl_base, unsigned int idx,
>> > + struct mtk_plane_state *state)
>> > +{
>> > + struct mtk_plane_pending_state *pending = &state->pending;
>> > + unsigned int addr = pending->addr;
>> > + unsigned int pitch = pending->pitch & 0x;
>> > + unsigned int fmt = pending->format;
>> > + unsigned int offset = (pending->y << 16) | pending->x;
>> > + unsigned int src_size = (pending->height << 16) | pending->width;
>> > + unsigned int con;
>> > +
>> > + con = has_rb_swapped(fmt) << 24 | ovl_fmt_convert(fmt) << 12;
>>
>> Call these conversion routines earlier (during atomic_check) and just add the
>> resulting "con" value to pending.
>
> You mean to add a .layer_atomic_check callback to the mtk_ddp_comp ops?
I didn't have any particular implementation in mind.
But, yeah... maybe a new "check" callback to pre-compute and formally
check the provided state.
This might be overkill though if it ends up adding a lot of overhead
for these values which can never really fail anyway.
> [...]
> How about this:
>
> static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
> {
> struct mtk_crtc_state *state;
>
> if (crtc->state) {
> if (crtc->state->mode_blob)
> drm_property_unreference_blob(crtc->state->mode_blob);
>
> state = to_mtk_crtc_state(crtc->state);
> memset(state, 0, sizeof(*state));
> } else {
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> if (!state)
> return;
> crtc->state = &state->base;
> }
>
> state->base.crtc = crtc;
> }
lgtm
> [...]
> Thanks for the review!
Thanks for the patches!!
>
> regards
> Philipp
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] pwm: lpc32xx: fixes in the LPC32xx PWM driver
On Sun, Dec 06, 2015 at 01:31:56PM +0200, Vladimir Zapolskiy wrote: > The changeset fixes a number of issues within current implementation > of LPC32xx PWM controller driver, namely > - the SoC has two independent PWM controllers with one channel each, > - runtime warnings from common clock framework, > - overflow in duty cycle calculation may result in disabled PWM, > - unsupported period values are not accepted. > > Correction of PWM channels requires a correspondent change in > arch/arm/boot/dts/lpc32xx.dtsi, it has been already sent for review. > > Changes from v1 to v2: > - corrected style of examples in documentation, > - improved commit messages > > Version v1 can be found here: > http://comments.gmane.org/gmane.linux.pwm/2828 > http://www.spinics.net/lists/devicetree/msg105398.html > > Vladimir Zapolskiy (6): > dt: lpc32xx: pwm: correct LPC32xx PWM device node example > dt: lpc32xx: pwm: update documentation of LPC32xx PWM device > pwm: lpc32xx: correct number of PWM channels from 2 to 1 > pwm: lpc32xx: fix warnings from common clock framework > pwm: lpc32xx: fix and simplify duty cycle and period calculations > pwm: lpc32xx: return ERANGE, if requested period is not supported > > .../devicetree/bindings/pwm/lpc32xx-pwm.txt| 9 +++- > drivers/pwm/pwm-lpc32xx.c | 59 > -- > 2 files changed, 29 insertions(+), 39 deletions(-) All patches applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH] usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller
Hi,
Arnd Bergmann writes:
>> +struct renesas_usb3;
>> +struct renesas_usb3_request {
>> +struct usb_request req;
>> +struct list_headqueue;
>> +};
>
> There is already a list_head in struct usb_request. Could you use that?
> (I don't know, just asking because this looks odd)
no, no. Don't do that. The list_head in usb_request is for use by the
gadget drivers and the gadget drivers only.
--
balbi
signature.asc
Description: PGP signature
[PATCH v3 7/7] media: s5p-mfc: add iommu support
This patch adds support for IOMMU to s5p-mfc device driver. MFC firmware
is limited and it cannot use the default configuration. If IOMMU is
available, the patch disables the default DMA address space
configuration and creates a new address space of size limited to 256M
and base address set to 0x2000.
For now the same address space is shared by both 'left' and 'right'
memory channels, because the DMA/IOMMU frameworks do not support
configuring them separately. This is not optimal, but besides limiting
total address space available has no other drawbacks (MFC firmware
supports 256M of address space per each channel).
Signed-off-by: Marek Szyprowski
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 24
drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 79 ++
2 files changed, 103 insertions(+)
create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 306344994c8e..bae7c0f7bfd4 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -30,6 +30,7 @@
#include "s5p_mfc_dec.h"
#include "s5p_mfc_enc.h"
#include "s5p_mfc_intr.h"
+#include "s5p_mfc_iommu.h"
#include "s5p_mfc_opr.h"
#include "s5p_mfc_cmd.h"
#include "s5p_mfc_pm.h"
@@ -1061,6 +1062,22 @@ static int s5p_mfc_configure_dma_memory(struct
s5p_mfc_dev *mfc_dev)
struct device *dev = &mfc_dev->plat_dev->dev;
/*
+* When IOMMU is available, we cannot use the default configuration,
+* because of MFC firmware requirements: address space limited to
+* 256M and non-zero default start address.
+* This is still simplified, not optimal configuration, but for now
+* IOMMU core doesn't allow to configure device's IOMMUs channel
+* separately.
+*/
+ if (exynos_is_iommu_available(dev)) {
+ int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
+S5P_MFC_IOMMU_DMA_SIZE);
+ if (ret == 0)
+ mfc_dev->mem_dev_l = mfc_dev->mem_dev_r = dev;
+ return ret;
+ }
+
+ /*
* Create and initialize virtual devices for accessing
* reserved memory regions.
*/
@@ -1078,6 +1095,13 @@ static int s5p_mfc_configure_dma_memory(struct
s5p_mfc_dev *mfc_dev)
static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
{
+ struct device *dev = &mfc_dev->plat_dev->dev;
+
+ if (exynos_is_iommu_available(dev)) {
+ exynos_unconfigure_iommu(dev);
+ return;
+ }
+
device_unregister(mfc_dev->mem_dev_l);
device_unregister(mfc_dev->mem_dev_r);
}
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
new file mode 100644
index ..5d1d1c2922e8
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics Co.Ltd
+ * Authors: Marek Szyprowski
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef S5P_MFC_IOMMU_H_
+#define S5P_MFC_IOMMU_H_
+
+#define S5P_MFC_IOMMU_DMA_BASE 0x2000lu
+#define S5P_MFC_IOMMU_DMA_SIZE SZ_256M
+
+#ifdef CONFIG_EXYNOS_IOMMU
+
+#include
+
+static inline bool exynos_is_iommu_available(struct device *dev)
+{
+ return dev->archdata.iommu != NULL;
+}
+
+static inline void exynos_unconfigure_iommu(struct device *dev)
+{
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+ arm_iommu_detach_device(dev);
+ arm_iommu_release_mapping(mapping);
+}
+
+static inline int exynos_configure_iommu(struct device *dev,
+unsigned int base, unsigned int size)
+{
+ struct dma_iommu_mapping *mapping = NULL;
+ int ret;
+
+ /* Disable the default mapping created by device core */
+ if (to_dma_iommu_mapping(dev))
+ exynos_unconfigure_iommu(dev);
+
+ mapping = arm_iommu_create_mapping(dev->bus, base, size);
+ if (IS_ERR(mapping)) {
+ pr_warn("Failed to create IOMMU mapping for device %s\n",
+ dev_name(dev));
+ return PTR_ERR(mapping);
+ }
+
+ ret = arm_iommu_attach_device(dev, mapping);
+ if (ret) {
+ pr_warn("Failed to attached device %s to IOMMU_mapping\n",
+ dev_name(dev));
+ arm_iommu_release_mapping(mapping);
+ return ret;
+ }
+
+ return 0;
+}
+
+#else
+
+static inline bool exynos_is_iommu_available(struct device *dev)
+{
+ return false;
+}
+
+static in
[PATCH v3 2/7] ARM: dts: exynos4412-odroid*: enable MFC device
Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
Odroid boards.
Signed-off-by: Marek Szyprowski
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 395c3ca9601e..349e6cc51283 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -18,6 +18,24 @@
stdout-path = &serial_1;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mfc_left: region@5100 {
+ compatible = "shared-dma-pool";
+ no-map;
+ reg = <0x5100 0x80>;
+ };
+
+ mfc_right: region@4300 {
+ compatible = "shared-dma-pool";
+ no-map;
+ reg = <0x4300 0x80>;
+ };
+ };
+
firmware@0204F000 {
compatible = "samsung,secure-firmware";
reg = <0x0204F000 0x1000>;
@@ -447,6 +465,12 @@
clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
};
+&mfc {
+ memory-region = <&mfc_left>, <&mfc_right>;
+ memory-region-names = "left", "right";
+ status = "okay";
+};
+
&mixer {
status = "okay";
};
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] ARM: Exynos: convert MFC device to generic reserved memory bindings
This patch replaces custom properties for definining reserved memory
regions with generic reserved memory bindings. All custom code for
handling MFC-specific reserved memory can be now removed from Exynos-DT
generic board code.
Signed-off-by: Marek Szyprowski
---
.../devicetree/bindings/media/s5p-mfc.txt | 16 ++--
arch/arm/boot/dts/exynos4210-origen.dts| 22 -
arch/arm/boot/dts/exynos4210-smdkv310.dts | 22 -
arch/arm/boot/dts/exynos4412-origen.dts| 22 -
arch/arm/boot/dts/exynos4412-smdk4412.dts | 22 -
arch/arm/boot/dts/exynos5250-arndale.dts | 22 -
arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 -
arch/arm/boot/dts/exynos5250-spring.dts| 22 -
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 22 -
arch/arm/boot/dts/exynos5420-smdk5420.dts | 22 -
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 -
arch/arm/mach-exynos/Makefile | 2 -
arch/arm/mach-exynos/exynos.c | 19 -
arch/arm/mach-exynos/mfc.h | 16
arch/arm/mach-exynos/s5p-dev-mfc.c | 94 --
15 files changed, 208 insertions(+), 159 deletions(-)
delete mode 100644 arch/arm/mach-exynos/mfc.h
delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2d5787eac91a..4603673c593b 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -21,16 +21,16 @@ Required properties:
- clock-names : from common clock binding: must contain "mfc",
corresponding to entry in the clocks property.
- - samsung,mfc-r : Base address of the first memory bank used by MFC
- for DMA contiguous memory allocation and its size.
-
- - samsung,mfc-l : Base address of the second memory bank used by MFC
- for DMA contiguous memory allocation and its size.
-
Optional properties:
- power-domains : power-domain property defined with a phandle
to respective power domain.
+ - memory-region : from reserved memory binding: phandles to two reserved
+ memory regions: accessed by "left" and "right" mfc memory bus
+ interfaces, used when no SYSMMU support is available
+ - memory-region-names : from reserved memory binding: must be "left"
+ and "right"
+
Example:
SoC specific DT entry:
@@ -46,6 +46,6 @@ mfc: codec@1340 {
Board specific DT entry:
codec@1340 {
- samsung,mfc-r = <0x4300 0x80>;
- samsung,mfc-l = <0x5100 0x80>;
+ memory-region = <&mfc_left>, <&mfc_right>;
+ memory-region-names = "left", "right";
};
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts
index 5821ad87e32c..4b7637dfa392 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -30,6 +30,24 @@
0x7000 0x1000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mfc_left: region@5100 {
+ compatible = "shared-dma-pool";
+ no-map;
+ reg = <0x5100 0x80>;
+ };
+
+ mfc_right: region@4300 {
+ compatible = "shared-dma-pool";
+ no-map;
+ reg = <0x4300 0x80>;
+ };
+ };
+
chosen {
bootargs ="root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC2,115200 init=/linuxrc";
stdout-path = &serial_2;
@@ -288,8 +306,8 @@
};
&mfc {
- samsung,mfc-r = <0x4300 0x80>;
- samsung,mfc-l = <0x5100 0x80>;
+ memory-region = <&mfc_left>, <&mfc_right>;
+ memory-region-names = "left", "right";
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos4210-smdkv310.dts
b/arch/arm/boot/dts/exynos4210-smdkv310.dts
index 104cbb33d2bb..efafc5721817 100644
--- a/arch/arm/boot/dts/exynos4210-smdkv310.dts
+++ b/arch/arm/boot/dts/exynos4210-smdkv310.dts
@@ -26,6 +26,24 @@
reg = <0x4000 0x8000>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mfc_left: region@5100 {
+ compatible = "shared-dma-pool";
+ no-map;
+ reg = <0x5100 0x80>;
+ };
+
+ mfc_right: region@4300 {
+ compatible = "shared-dma-pool";
+ no-map;
+ reg = <0x4300 0x800
[PATCH v3 3/7] of: reserved_mem: add support for named reserved mem nodes
This patch allows device drivers to initialize more than one reserved
memory region assigned to given device. When driver needs to use more
than one reserved memory region, it should allocate child devices and
initialize regions by index or name for each of its child devices.
Signed-off-by: Marek Szyprowski
---
.../bindings/reserved-memory/reserved-memory.txt | 2 +
.../devicetree/bindings/resource-names.txt | 1 +
drivers/of/of_reserved_mem.c | 104 +
include/linux/of_reserved_mem.h| 31 +-
4 files changed, 115 insertions(+), 23 deletions(-)
diff --git
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index 3da0ebdba8d9..43a14957fd64 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -74,6 +74,8 @@ Regions in the /reserved-memory node may be referenced by
other device
nodes by adding a memory-region property to the device node.
memory-region (optional) - phandle, specifier pairs to children of
/reserved-memory
+memory-region-names (optional) - supplemental names property, provide array of
+names to identify memory regions
Example
---
diff --git a/Documentation/devicetree/bindings/resource-names.txt
b/Documentation/devicetree/bindings/resource-names.txt
index e280fef6f265..51823e99b983 100644
--- a/Documentation/devicetree/bindings/resource-names.txt
+++ b/Documentation/devicetree/bindings/resource-names.txt
@@ -12,6 +12,7 @@ Resource Property Supplemental Names Property
regreg-names
clocks clock-names
interrupts interrupt-names
+memory-region memory-region-names
Usage:
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1a3556a9e9ea..c58b362aaa63 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define MAX_RESERVED_REGIONS 16
static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -287,53 +288,116 @@ static inline struct reserved_mem *__find_rmem(struct
device_node *node)
return NULL;
}
+struct rmem_assigned_device {
+ struct device *dev;
+ struct reserved_mem *rmem;
+ struct list_head list;
+};
+
+static LIST_HEAD(of_rmem_assigned_device_list);
+static DEFINE_MUTEX(of_rmem_assigned_device_mutex);
+
/**
* of_reserved_mem_device_init() - assign reserved memory region to given
device
+ * @dev: Pointer to the device to configure
+ * @np:Pointer to the device_node with 'reserved-memory'
property
+ * @idx: Index of selected region
+ *
+ * This function assigns respective DMA-mapping operations based on reserved
+ * memory region specified by 'memory-region' property in @np node to the @dev
+ * device. When driver needs to use more than one reserved memory region, it
+ * should allocate child devices and initialize regions by name for each of
+ * child device.
*
- * This function assign memory region pointed by "memory-region" device tree
- * property to the given device.
+ * Returns error code or zero on success.
*/
-int of_reserved_mem_device_init(struct device *dev)
+int of_reserved_mem_init(struct device *dev, struct device_node *np, int idx)
{
+ struct rmem_assigned_device *rd;
+ struct device_node *target;
struct reserved_mem *rmem;
- struct device_node *np;
int ret;
- np = of_parse_phandle(dev->of_node, "memory-region", 0);
- if (!np)
- return -ENODEV;
+ if (!np || !dev)
+ return -EINVAL;
+
+ target = of_parse_phandle(np, "memory-region", idx);
+ if (!target)
+ return -EINVAL;
- rmem = __find_rmem(np);
- of_node_put(np);
+ rmem = __find_rmem(target);
+ of_node_put(target);
if (!rmem || !rmem->ops || !rmem->ops->device_init)
return -EINVAL;
+ rd = kmalloc(sizeof(struct rmem_assigned_device), GFP_KERNEL);
+ if (!rd)
+ return -ENOMEM;
+
ret = rmem->ops->device_init(rmem, dev);
- if (ret == 0)
+ if (ret == 0) {
+ rd->dev = dev;
+ rd->rmem = rmem;
+
+ mutex_lock(&of_rmem_assigned_device_mutex);
+ list_add(&rd->list, &of_rmem_assigned_device_list);
+ mutex_unlock(&of_rmem_assigned_device_mutex);
+
dev_info(dev, "assigned reserved memory node %s\n", rmem->name);
+ } else {
+ kfree(rd);
+ }
return ret;
}
-EXPORT_SYMBOL_GPL(of_reserved_mem_device_init);
+EXPORT_SYMBOL_GPL(of_reserved_mem_init);
+
+/**
+ * of_reserved_mem_device_init() - assign reserved memory region to given
device
+ * @dev
[PATCH v3 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support
Hello, This patchset finally perform cleanup of custom code in s5p-mfc codec driver. The first part is removal of custom, driver specific code for intializing and handling of reserved memory. Instead, a generic code for reserved memory regions is used. Then, once it is done, the proper setup of DMA parameters (max segment size) is applied for all multimedia devices found on Exynos SoCs to let them properly handle shared buffers mapped into contiguous DMA address space. The last patch adds support for IOMMU to MFC driver. Some additional code is needed because of specific requirements of MFC device firmware (see patch 7 for more details). When no IOMMU is available, the code fallbacks to generic reserved memory regions. After applying this patchset, MFC device works correctly when IOMMU is either enabled or disabled. Patches have been tested on top of linux-next from 20151207. I would prefer to merge patches 1-2 via Samsung tree and patches 3-7 via media tree (there are no compile-time dependencies between patches 1-2 and 3-7). Patches have been tested on Odroid U3 (Exynos 4412 based) and Odroid XU3 (Exynos 5422 based) boards. Best regards Marek Szyprowski Samsung R&D Institute Poland Changelog: v3: - fixed issues pointed by Laurent Pinchart: - added documentation to memory-region-names property, - changed devm_kzalloc to kzalloc in vb2_dma_contig_set_max_seg_size() to avoid access to freed memory after reloading driver module - unified odroid mfc reserved memory configuration with other Exynos4 boards v2: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/97025 - reworked of_reserved_mem_init* functions on request from Rob Herring, added separate index and name based selection of reserved region - adapted for of_reserved_mem_init* related changes v1: https://www.mail-archive.com/linux-media@vger.kernel.org/msg94100.html - initial version of another approach for this problem, rewrote driver code for new reserved memory bindings, which finally have been merged some time ago v0: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/189259.html - old patchset solving the same problem, abandoned due to other tasks and long time of merging reserved memory bindings and support code for it Patch summary: Marek Szyprowski (7): ARM: Exynos: convert MFC device to generic reserved memory bindings ARM: dts: exynos4412-odroid*: enable MFC device of: reserved_mem: add support for named reserved mem nodes media: vb2-dma-contig: add helper for setting dma max seg size media: set proper max seg size for devices on Exynos SoCs media: s5p-mfc: replace custom reserved memory init code with generic one media: s5p-mfc: add iommu support .../devicetree/bindings/media/s5p-mfc.txt | 16 +-- .../bindings/reserved-memory/reserved-memory.txt | 2 + .../devicetree/bindings/resource-names.txt | 1 + arch/arm/boot/dts/exynos4210-origen.dts| 22 ++- arch/arm/boot/dts/exynos4210-smdkv310.dts | 22 ++- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 24 arch/arm/boot/dts/exynos4412-origen.dts| 22 ++- arch/arm/boot/dts/exynos4412-smdk4412.dts | 22 ++- arch/arm/boot/dts/exynos5250-arndale.dts | 22 ++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 ++- arch/arm/boot/dts/exynos5250-spring.dts| 22 ++- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 22 ++- arch/arm/boot/dts/exynos5420-smdk5420.dts | 22 ++- arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 ++- arch/arm/mach-exynos/Makefile | 2 - arch/arm/mach-exynos/exynos.c | 19 --- arch/arm/mach-exynos/mfc.h | 16 --- arch/arm/mach-exynos/s5p-dev-mfc.c | 94 - drivers/media/platform/exynos-gsc/gsc-core.c | 1 + drivers/media/platform/exynos4-is/fimc-core.c | 1 + drivers/media/platform/exynos4-is/fimc-is.c| 1 + drivers/media/platform/exynos4-is/fimc-lite.c | 1 + drivers/media/platform/s5p-g2d/g2d.c | 1 + drivers/media/platform/s5p-jpeg/jpeg-core.c| 1 + drivers/media/platform/s5p-mfc/s5p_mfc.c | 153 - drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 79 +++ drivers/media/platform/s5p-tv/mixer_video.c| 1 + drivers/media/v4l2-core/videobuf2-dma-contig.c | 14 ++ drivers/of/of_reserved_mem.c | 104 +++--- include/linux/of_reserved_mem.h| 31 - include/media/videobuf2-dma-contig.h | 1 + 31 files changed, 535 insertions(+), 248 deletions(-) delete mode 100644 arch/arm/mach-exynos/mfc.h delete mode 100644 arch/arm/mach-exynos/s5p-dev-mfc.c create mode 100644 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree
[PATCH v3 5/7] media: set proper max seg size for devices on Exynos SoCs
All multimedia devices found on Exynos SoCs support only contiguous
buffers, so set DMA max segment size to DMA_BIT_MASK(32) to let memory
allocator to correctly create contiguous memory mappings.
Signed-off-by: Marek Szyprowski
---
drivers/media/platform/exynos-gsc/gsc-core.c | 1 +
drivers/media/platform/exynos4-is/fimc-core.c | 1 +
drivers/media/platform/exynos4-is/fimc-is.c | 1 +
drivers/media/platform/exynos4-is/fimc-lite.c | 1 +
drivers/media/platform/s5p-g2d/g2d.c | 1 +
drivers/media/platform/s5p-jpeg/jpeg-core.c | 1 +
drivers/media/platform/s5p-mfc/s5p_mfc.c | 2 ++
drivers/media/platform/s5p-tv/mixer_video.c | 1 +
8 files changed, 9 insertions(+)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 9b9e423e4fc4..4f90be43b5a9 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1140,6 +1140,7 @@ static int gsc_probe(struct platform_device *pdev)
goto err_m2m;
/* Initialize continious memory allocator */
+ vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
gsc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(gsc->alloc_ctx)) {
ret = PTR_ERR(gsc->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
b/drivers/media/platform/exynos4-is/fimc-core.c
index cef2a7f07cdb..368e19b50498 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -1019,6 +1019,7 @@ static int fimc_probe(struct platform_device *pdev)
}
/* Initialize contiguous memory allocator */
+ vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c
b/drivers/media/platform/exynos4-is/fimc-is.c
index 49658ca39e51..123772fa0241 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -841,6 +841,7 @@ static int fimc_is_probe(struct platform_device *pdev)
if (ret < 0)
goto err_pm;
+ vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
is->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(is->alloc_ctx)) {
ret = PTR_ERR(is->alloc_ctx);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index 6f76afd909c4..9cfd2221f53d 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -1564,6 +1564,7 @@ static int fimc_lite_probe(struct platform_device *pdev)
goto err_sd;
}
+ vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
diff --git a/drivers/media/platform/s5p-g2d/g2d.c
b/drivers/media/platform/s5p-g2d/g2d.c
index e1936d9d27da..31f6c233b146 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -681,6 +681,7 @@ static int g2d_probe(struct platform_device *pdev)
goto put_clk_gate;
}
+ vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
dev->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
if (IS_ERR(dev->alloc_ctx)) {
ret = PTR_ERR(dev->alloc_ctx);
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 4a608cbe0fdb..6bd92f014a23 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -2839,6 +2839,7 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
goto device_register_rollback;
}
+ vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32));
jpeg->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
if (IS_ERR(jpeg->alloc_ctx)) {
v4l2_err(&jpeg->v4l2_dev, "Failed to init memory allocator\n");
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3ffe2ecfd5ef..3e9cdafe2168 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1143,11 +1143,13 @@ static int s5p_mfc_probe(struct platform_device *pdev)
}
}
+ vb2_dma_contig_set_max_seg_size(dev->mem_dev_l, DMA_BIT_MASK(32));
dev->alloc_ctx[0] = vb2_dma_contig_init_ctx(dev->mem_dev_l);
if (IS_ERR(dev->alloc_ctx[0])) {
ret = PTR_ERR(dev->alloc_ctx[0]);
goto err_res;
}
+ vb2_dma_contig_set_max_seg_size(dev->mem_dev_r, DMA_BIT_MASK(32));
dev->alloc_ctx[1] = vb2_dma_contig_init_ctx(dev->mem
[PATCH v3 6/7] media: s5p-mfc: replace custom reserved memory init code with generic one
This patch removes custom code for initialization and handling of
reserved memory regions in s5p-mfc driver and replaces it with generic
named reserved memory regions specified in device tree.
s5p-mfc driver now handles two reserved memory regions: "left" and
"right", defined by generic reserved memory bindings. Support for non-dt
platform has been removed, because all supported platforms have been
converted to device tree.
Signed-off-by: Marek Szyprowski
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 129 +++
1 file changed, 62 insertions(+), 67 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3e9cdafe2168..306344994c8e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "s5p_mfc_common.h"
#include "s5p_mfc_ctrl.h"
@@ -1022,55 +1023,67 @@ static const struct v4l2_file_operations s5p_mfc_fops =
{
.mmap = s5p_mfc_mmap,
};
-static int match_child(struct device *dev, void *data)
+/* DMA memory related helper functions */
+static void s5p_mfc_memdev_release(struct device *dev)
{
- if (!dev_name(dev))
- return 0;
- return !strcmp(dev_name(dev), (char *)data);
+ of_reserved_mem_device_release(dev);
}
-static void *mfc_get_drv_data(struct platform_device *pdev);
-
-static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
+static struct device *s5p_mfc_alloc_memdev(struct device *dev, const char
*name)
{
- unsigned int mem_info[2] = { };
+ struct device *child;
+ int ret;
- dev->mem_dev_l = devm_kzalloc(&dev->plat_dev->dev,
- sizeof(struct device), GFP_KERNEL);
- if (!dev->mem_dev_l) {
- mfc_err("Not enough memory\n");
- return -ENOMEM;
- }
- device_initialize(dev->mem_dev_l);
- of_property_read_u32_array(dev->plat_dev->dev.of_node,
- "samsung,mfc-l", mem_info, 2);
- if (dma_declare_coherent_memory(dev->mem_dev_l, mem_info[0],
- mem_info[0], mem_info[1],
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
- mfc_err("Failed to declare coherent memory for\n"
- "MFC device\n");
- return -ENOMEM;
+ child = devm_kzalloc(dev, sizeof(struct device), GFP_KERNEL);
+ if (!child)
+ return NULL;
+
+ device_initialize(child);
+ dev_set_name(child, "%s:%s", dev_name(dev), name);
+ child->parent = dev;
+ child->bus = dev->bus;
+ child->coherent_dma_mask = dev->coherent_dma_mask;
+ child->dma_mask = dev->dma_mask;
+ child->release = s5p_mfc_memdev_release;
+
+ if (device_add(child) == 0) {
+ ret = of_reserved_mem_init_by_name(child, dev->of_node, name);
+ if (ret == 0)
+ return child;
}
- dev->mem_dev_r = devm_kzalloc(&dev->plat_dev->dev,
- sizeof(struct device), GFP_KERNEL);
- if (!dev->mem_dev_r) {
- mfc_err("Not enough memory\n");
- return -ENOMEM;
- }
- device_initialize(dev->mem_dev_r);
- of_property_read_u32_array(dev->plat_dev->dev.of_node,
- "samsung,mfc-r", mem_info, 2);
- if (dma_declare_coherent_memory(dev->mem_dev_r, mem_info[0],
- mem_info[0], mem_info[1],
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
- pr_err("Failed to declare coherent memory for\n"
- "MFC device\n");
- return -ENOMEM;
+ put_device(child);
+ return NULL;
+}
+
+static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+{
+ struct device *dev = &mfc_dev->plat_dev->dev;
+
+ /*
+* Create and initialize virtual devices for accessing
+* reserved memory regions.
+*/
+ mfc_dev->mem_dev_l = s5p_mfc_alloc_memdev(dev, "left");
+ if (!mfc_dev->mem_dev_l)
+ return -ENODEV;
+ mfc_dev->mem_dev_r = s5p_mfc_alloc_memdev(dev, "right");
+ if (!mfc_dev->mem_dev_r) {
+ device_unregister(mfc_dev->mem_dev_l);
+ return -ENODEV;
}
+
return 0;
}
+static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+{
+ device_unregister(mfc_dev->mem_dev_l);
+ device_unregister(mfc_dev->mem_dev_r);
+}
+
+static void *mfc_get_drv_data(struct platform_device *pdev);
+
/* MFC probe function */
static int s5p_mfc_probe(struct platform_device *pdev)
{
@@ -1096,12 +1109,6 @@ static int s5p_mfc_probe(struct platform_device *pdev)
dev->variant = mfc_get_drv_data(pdev);
- ret = s5p_mfc_init_pm(dev);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed
[PATCH v3 4/7] media: vb2-dma-contig: add helper for setting dma max seg size
Add a helper function for device drivers to set DMA's max_seg_size.
Setting it to largest possible value lets DMA-mapping API always create
contiguous mappings in DMA address space. This is essential for all
devices, which use dma-contig videobuf2 memory allocator and shared
buffers.
Signed-off-by: Marek Szyprowski
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 14 ++
include/media/videobuf2-dma-contig.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index c33127284cfe..bd893788d1ae 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -742,6 +742,20 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
}
EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
+{
+ if (!dev->dma_parms) {
+ dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
+ if (!dev->dma_parms)
+ return -ENOMEM;
+ }
+ if (dma_get_max_seg_size(dev) < size)
+ return dma_set_max_seg_size(dev, size);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
+
MODULE_DESCRIPTION("DMA-contig memory handling routines for videobuf2");
MODULE_AUTHOR("Pawel Osciak ");
MODULE_LICENSE("GPL");
diff --git a/include/media/videobuf2-dma-contig.h
b/include/media/videobuf2-dma-contig.h
index c33dfa69d7ab..0e6ba644939e 100644
--- a/include/media/videobuf2-dma-contig.h
+++ b/include/media/videobuf2-dma-contig.h
@@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb, unsigned
int plane_no)
void *vb2_dma_contig_init_ctx(struct device *dev);
void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
+int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size);
extern const struct vb2_mem_ops vb2_dma_contig_memops;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver
On Tue, Dec 15, 2015 at 12:37:34PM +, Robin Murphy wrote: > The potential issue I *do* see, looking more closely, is that > iommu_group_get_for_dev() is setting group->domain but not calling > the attach_dev callback, which looks wrong... Attaching the device happens from iommu_group_add_device(), which is called from iommu_group_get_for_dev() right after the domains are allocated/initialized. Joerg -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] devicetree: add vendor prefix for Kyocera Corporation
On Wed, Dec 02, 2015 at 07:41:10PM +0100, Lucas Stach wrote: > KYO is the stock ticker symbol of Kyocera Corporation. > > Signed-off-by: Lucas Stach > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Both patches applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH 0/8] Add support for CL-SOM-iMX7 and SBC-iMX7
Hi Shawn, On 12/14/15 04:47, Shawn Guo wrote: > On Mon, Dec 07, 2015 at 09:14:31AM +0200, Ilya Ledvich wrote: >> Ilya Ledvich (8): >> ARM: dts: imx7d: cl-som-imx7: add basic module support >> ARM: dts: imx7d: cl-som-imx7: add usb otg support >> ARM: dts: imx7d: cl-som-imx7: add eMMC support >> ARM: dts: imx7d: cl-som-imx7: add fec1 support >> ARM: dts: imx7d: cl-som-imx7: add eeprom support >> ARM: dts: imx7d: cl-som-imx7: add gpio extender support >> ARM: dts: imx7d: cl-som-imx7: add fec2 support > > For the initial board support submission, it doesn't really need such > splitting. Please merge above patches into one. Yeah, I know there is no need for such splitting, yet I think if the splitting is done right - it is much simpler to review, it provides a better bisectability (in case it will be needed in the future), and also if for some reason one (or more) patches are needing some time consuming rework, others (earlier ones in the series) can be accepted meanwhile. So, I really like to keep it this way, unless you insist. Thanks! -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: imx7d: cl-som-imx7: add basic module support
Hi Shawn,
On 12/14/15 04:43, Shawn Guo wrote:
> On Thu, Dec 10, 2015 at 04:01:37PM +0200, Igor Grinberg wrote:
>> From: Ilya Ledvich
[...]
>> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
>> b/Documentation/devicetree/bindings/arm/fsl.txt
>> index 34c88b0..30b0ba1 100644
>> --- a/Documentation/devicetree/bindings/arm/fsl.txt
>> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
>> @@ -53,6 +53,10 @@ i.MX6 Quad SABRE Automotive Board
>> Required root node properties:
>> - compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
>>
>> +i.MX7D CL-SOM-iMX7 Board
>> +Required root node properties:
>> +- compatible = "compulab,cl-som-imx7", "fsl,imx7d";
>> +
>
> This is not a board produced by FSL, so it should be documented in
> fsl.txt.
You mean _should not_ be documented in fsl.txt, right?
Ok, I have no problem with that, we've just used the same approach OMAP
takes - all the OMAP based boards are documented in the same file:
Documentation/devicetree/bindings/arm/omap/omap.txt
Do you think we should document it in:
Documentation/devicetree/bindings/arm/compulab-boards.txt
(this file should already exist in arm-soc/next/dt)?
>
>> Generic i.MX boards
>> ---
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 30bbc37..83ed521 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -350,6 +350,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
>> dtb-$(CONFIG_SOC_IMX6UL) += \
>> imx6ul-14x14-evk.dtb
>> dtb-$(CONFIG_SOC_IMX7D) += \
>> +imx7d-cl-som-imx7.dtb \
>> imx7d-sdb.dtb
>> dtb-$(CONFIG_SOC_LS1021A) += \
>> ls1021a-qds.dtb \
>> diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
>> b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
>> new file mode 100644
>> index 000..ba05198
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
>> @@ -0,0 +1,150 @@
>> +/*
>> + * Support for CompuLab CL-SOM-iMX7 System-on-Module
>> + *
>> + * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
>> + * Author: Ilya Ledvich
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published
>> by
>> + * the Free Software Foundation.
>> + */
>
> GPL/X11 dual licence is generally suggested for newly added dts files,
> as it will let non-Linux OS use them.
I don't remember we've used this one before...
Can you please point to an example?
[...]
>> +&iomuxc {
>> +cl-som-imx7 {
>
> Since commit (5fcdf6a7ed95 pinctrl: imx: Allow parsing DT without
> function nodes), this level of container node is not really needed any
> more.
Ok. Will be done for the next version. Thanks!
>
> Shawn
>
>> +pinctrl_i2c2: i2c2grp {
>> +fsl,pins = <
>> +MX7D_PAD_I2C2_SDA__I2C2_SDA
>> 0x407f
>> +MX7D_PAD_I2C2_SCL__I2C2_SCL
>> 0x407f
>> +>;
>> +};
>> +
>> +pinctrl_uart1: uart1grp {
>> +fsl,pins = <
>> +MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX0x79
>> +MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX0x79
>> +>;
>> +};
>> +};
>> +};
>> --
>> 2.4.10
>>
>>
>
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] devicetree: sound: add binding for WM8974 codec
This adds a binding for the Wolfson WM8974 mono audio codec.
Signed-off-by: Mans Rullgard
---
Sending this patch again, this time including Mark Brown.
---
Documentation/devicetree/bindings/sound/wlf,wm8974.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.txt
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
new file mode 100644
index 000..01d3a7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
@@ -0,0 +1,15 @@
+WM8974 audio CODEC
+
+This device supports both I2C and SPI (configured with pin strapping
+on the board).
+
+Required properties:
+ - compatible: "wlf,wm8974"
+ - reg: the I2C address or SPI chip select number of the device
+
+Examples:
+
+codec: wm8974@1a {
+ compatible = "wlf,wm8974";
+ reg = <0x1a>;
+};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: config: Add the rk3036 configure for kylin board
Hi Caesar, Am Mittwoch, 16. Dezember 2015, 16:27:21 schrieb Caesar Wang: > Add RK3036-specific configuration for Kylin board. > > Signed-off-by: Caesar Wang I don't think we generally do per-board defconfigs in the mainline kernel anymore. If you are missing specific functionality, please add them as patch to the multi_v7_defconfig (ideally as module). Heiko > > --- > > arch/arm/configs/rk3036_kylin_defconfig | 230 > 1 file changed, 230 insertions(+) > create mode 100644 arch/arm/configs/rk3036_kylin_defconfig > > diff --git a/arch/arm/configs/rk3036_kylin_defconfig > b/arch/arm/configs/rk3036_kylin_defconfig new file mode 100644 > index 000..692c393 > --- /dev/null > +++ b/arch/arm/configs/rk3036_kylin_defconfig > @@ -0,0 +1,230 @@ > +CONFIG_CROSS_COMPILE="arm-linux-gnueabi-" > +# CONFIG_LOCALVERSION_AUTO is not set > +CONFIG_DEFAULT_HOSTNAME="radxarock" > +CONFIG_SYSVIPC=y > +# CONFIG_USELIB is not set > +CONFIG_AUDIT=y > +CONFIG_IRQ_DOMAIN_DEBUG=y > +CONFIG_BLK_DEV_INITRD=y > +CONFIG_CC_OPTIMIZE_FOR_SIZE=y > +CONFIG_PERF_EVENTS=y > +# CONFIG_COMPAT_BRK is not set > +CONFIG_SLAB=y > +CONFIG_JUMP_LABEL=y > +CONFIG_MODULES=y > +CONFIG_MODULE_FORCE_LOAD=y > +CONFIG_MODULE_UNLOAD=y > +CONFIG_PARTITION_ADVANCED=y > +# CONFIG_IOSCHED_CFQ is not set > +CONFIG_ARCH_ROCKCHIP=y > +CONFIG_PL310_ERRATA_588369=y > +CONFIG_PL310_ERRATA_727915=y > +CONFIG_ARM_ERRATA_720789=y > +CONFIG_ARM_ERRATA_754322=y > +CONFIG_SMP=y > +CONFIG_NR_CPUS=2 > +CONFIG_PREEMPT_VOLUNTARY=y > +CONFIG_AEABI=y > +CONFIG_HIGHMEM=y > +# CONFIG_COMPACTION is not set > +CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 > +CONFIG_CLEANCACHE=y > +CONFIG_FRONTSWAP=y > +CONFIG_ZBOOT_ROM_TEXT=0x0 > +CONFIG_ARM_APPENDED_DTB=y > +CONFIG_ARM_ATAG_DTB_COMPAT=y > +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y > +CONFIG_CPU_FREQ=y > +CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y > +CONFIG_CPU_FREQ_GOV_POWERSAVE=y > +CONFIG_CPUFREQ_DT=y > +CONFIG_CPU_IDLE=y > +CONFIG_VFP=y > +CONFIG_NEON=y > +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set > +CONFIG_PM_WAKELOCKS=y > +CONFIG_PM_DEBUG=y > +CONFIG_NET=y > +CONFIG_PACKET=y > +CONFIG_UNIX=y > +CONFIG_INET=y > +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set > +# CONFIG_INET_XFRM_MODE_TUNNEL is not set > +# CONFIG_INET_XFRM_MODE_BEET is not set > +# CONFIG_INET_LRO is not set > +# CONFIG_INET_DIAG is not set > +# CONFIG_IPV6 is not set > +CONFIG_CFG80211_WEXT=y > +CONFIG_RFKILL=y > +CONFIG_DEVTMPFS=y > +CONFIG_DEVTMPFS_MOUNT=y > +# CONFIG_FIRMWARE_IN_KERNEL is not set > +CONFIG_BLK_DEV_LOOP=y > +CONFIG_BLK_DEV_RAM=y > +CONFIG_BLK_DEV_RAM_COUNT=1 > +CONFIG_BLK_DEV_RAM_SIZE=16384 > +CONFIG_SRAM=y > +CONFIG_SCSI=y > +# CONFIG_SCSI_PROC_FS is not set > +CONFIG_BLK_DEV_SD=y > +# CONFIG_SCSI_LOWLEVEL is not set > +CONFIG_NETDEVICES=y > +# CONFIG_NET_CADENCE is not set > +# CONFIG_NET_VENDOR_BROADCOM is not set > +# CONFIG_NET_VENDOR_CIRRUS is not set > +# CONFIG_NET_VENDOR_FARADAY is not set > +# CONFIG_NET_VENDOR_INTEL is not set > +# CONFIG_NET_VENDOR_MARVELL is not set > +# CONFIG_NET_VENDOR_MICREL is not set > +# CONFIG_NET_VENDOR_NATSEMI is not set > +# CONFIG_NET_VENDOR_SAMSUNG is not set > +# CONFIG_NET_VENDOR_SEEQ is not set > +# CONFIG_NET_VENDOR_SMSC is not set > +CONFIG_STMMAC_ETH=y > +# CONFIG_NET_VENDOR_VIA is not set > +# CONFIG_NET_VENDOR_WIZNET is not set > +CONFIG_SMSC_PHY=y > +# CONFIG_INPUT_MOUSEDEV_PSAUX is not set > +CONFIG_INPUT_MOUSEDEV_SCREEN_X=800 > +CONFIG_INPUT_MOUSEDEV_SCREEN_Y=600 > +CONFIG_INPUT_EVDEV=y > +# CONFIG_KEYBOARD_ATKBD is not set > +CONFIG_KEYBOARD_GPIO=y > +CONFIG_KEYBOARD_GPIO_POLLED=y > +# CONFIG_INPUT_MOUSE is not set > +CONFIG_INPUT_TOUCHSCREEN=y > +CONFIG_INPUT_MISC=y > +# CONFIG_SERIO is not set > +# CONFIG_LEGACY_PTYS is not set > +# CONFIG_DEVKMEM is not set > +CONFIG_SERIAL_8250=y > +CONFIG_SERIAL_8250_CONSOLE=y > +CONFIG_SERIAL_8250_DW=y > +# CONFIG_HW_RANDOM is not set > +CONFIG_I2C_CHARDEV=y > +CONFIG_I2C_GPIO=y > +CONFIG_I2C_RK3X=y > +CONFIG_GPIO_DWAPB=y > +CONFIG_POWER_SUPPLY=y > +CONFIG_POWER_RESET=y > +CONFIG_SENSORS_IIO_HWMON=y > +CONFIG_THERMAL=y > +CONFIG_CPU_THERMAL=y > +CONFIG_WATCHDOG=y > +CONFIG_SOFT_WATCHDOG=y > +CONFIG_MFD_RK808=y > +CONFIG_MFD_TPS65910=y > +CONFIG_REGULATOR_DEBUG=y > +CONFIG_REGULATOR_FIXED_VOLTAGE=y > +CONFIG_REGULATOR_ACT8865=y > +CONFIG_REGULATOR_FAN53555=y > +CONFIG_REGULATOR_RK808=y > +CONFIG_DRM=y > +CONFIG_DRM_ROCKCHIP=y > +CONFIG_ROCKCHIP_DW_HDMI=y > +CONFIG_ROCKCHIP_INNO_HDMI=y > +CONFIG_DRM_PANEL_SIMPLE=y > +CONFIG_FB_MODE_HELPERS=y > +CONFIG_BACKLIGHT_LCD_SUPPORT=y > +CONFIG_LCD_CLASS_DEVICE=y > +CONFIG_BACKLIGHT_CLASS_DEVICE=y > +# CONFIG_BACKLIGHT_GENERIC is not set > +CONFIG_BACKLIGHT_PWM=y > +CONFIG_SOUND=y > +CONFIG_SND=y > +CONFIG_SND_SOC=y > +CONFIG_SND_SOC_ROCKCHIP=y > +CONFIG_SND_SOC_ROCKCHIP_I2S=y > +CONFIG_SND_SIMPLE_CARD=y > +CONFIG_USB=y > +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y > +CONFIG_USB_OTG=y > +CONFIG_USB_MON=y > +CONFIG_USB_STORAGE=y > +CONFIG_USB_DWC2=y > +CONFIG_USB_DWC2_PLATFOR
Re: [PATCH 1/2] devicetree: sound: add binding for WM8974 codec
Mark Brown writes: > On Wed, Dec 16, 2015 at 01:31:30PM +, Måns Rullgård wrote: > >> This is the 1/1 you were missing. > > I need the patch in a form I can apply. I assumed your email client had some way of displaying the message I replied to. Guess I was wrong. >> Am I the only one who is annoyed by scripts/get_maintainer.pl not >> returning all the addresses it should in cases like this? Is there some >> trick I'm missing? > > You can't blindly rely on get_maintainers, it's prone to both false > positives (CCing too many people, especially if you enable git matching > when it often starts spamming people who are just doing global cleanups) > and false negatives (if you don't enable git matching and it misses > people who care about a specific driver). So in short, I'm supposed to magically divine who wants to see what. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] ARM: dts: rockchip: update the core dts for rk3036
Hi Caesar,
Am Mittwoch, 16. Dezember 2015, 16:27:19 schrieb Caesar Wang:
> Update the core dts for rk3036 SoCs.
>
> 1) Add the display (lcdc, hdmi, vop...) device node.
> 2) modify the i2s name to i2s0 and i2s1.
>Although there is only one i2s IP inside the rk3036,
>we need use all of the gpios of i2s0 and i2s1.
>So, we add the i2s1 IP is the same with i2s0 to support the
>different gpios.
> 3) Add sdio for wifi module, sdmmc for sd card.
if you need a list to describe changes, it is a good indication that this
needs to be split into separate patches.
> Signed-off-by: Caesar Wang
> ---
>
> arch/arm/boot/dts/rk3036.dtsi | 225
> +- 1 file changed, 221
> insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
> index f8758bf..574c56c 100644
> --- a/arch/arm/boot/dts/rk3036.dtsi
> +++ b/arch/arm/boot/dts/rk3036.dtsi
> @@ -55,6 +55,7 @@
> i2c1 = &i2c1;
> i2c2 = &i2c2;
> mshc0 = &emmc;
> + mshc1 = &sdmmc;
> serial0 = &uart0;
> serial1 = &uart1;
> serial2 = &uart2;
> @@ -145,6 +146,63 @@
> };
> };
>
> + lcdc_mmu: iommu@10118300 {
> + compatible = "rockchip,iommu";
> + reg = <0x10118300 0x100>;
> + interrupts = ;
> + interrupt-names = "lcdc_mmu";
> + #iommu-cells = <0>;
> + status = "disabled";
> + };
> +
> + lcdc: lcdc@10118000 {
> + compatible = "rockchip,rk3036-lcdc";
> + reg = <0x10118000 0x19c>;
> + interrupts = ;
> + clocks = <&cru ACLK_LCDC>, <&cru SCLK_LCDC>, <&cru HCLK_LCDC>;
> + clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
> + resets = <&cru SRST_LCDC1_A>, <&cru SRST_LCDC1_H>, <&cru
> SRST_LCDC1_D>;
> + reset-names = "axi", "ahb", "dclk";
> + iommus = <&lcdc_mmu>;
> +
> + status = "disabled";
> +
> + lcdc_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lcdc_out_hdmi: endpoint@0 {
> + reg = <1>;
> + remote-endpoint = <&hdmi_in_lcdc>;
> + };
> + };
> + };
please only add nodes for things _after_ they are posted and applied by the
maintainer (Mark Yao in this case)
> + hdmi: hdmi@20034000 {
> + compatible = "rockchip,rk3036-inno-hdmi";
> + reg = <0x20034000 0x4000>;
> + interrupts = ;
> + clocks = <&cru PCLK_HDMI>;
> + clock-names = "pclk";
> + rockchip,grf = <&grf>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_ctl>;
> + status = "disabled";
> +
> + hdmi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + hdmi_in_lcdc: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&lcdc_out_hdmi>;
> + };
> + };
> + };
same as above
> +
> + display-subsystem {
> + compatible = "rockchip,display-subsystem";
> + ports = <&lcdc_out>;
> + };
> +
> gic: interrupt-controller@10139000 {
> compatible = "arm,gic-400";
> interrupt-controller;
> @@ -158,6 +216,21 @@
> interrupts = ;
> };
>
> + usbphy: phy {
> + compatible = "rockchip,rk3036-usb-phy";
> + rockchip,grf = <&grf>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> +
> + usbphy0: usb-phy0 {
> + #phy-cells = <0>;
> + reg = <0x17c>;
> + clocks = <&cru SCLK_OTGPHY0>;
> + clock-names = "phyclk";
> + };
> + };
> +
same as above - no driver. With the addition, that the usbphy on rk3036,
rk3368 (and probably more) is a new IP (Innosilicon it seems instead of the
DWC picophy) and includes a whole additional set of function registers
(GRF_USBPHYx_CONy...) to control the phy block, so this should definitly also
be a separate driver.
Especially also as I'm not yet clear on the clock situation.
On rk3036 sclk_otgphy0 seems to be supplying the phyblock directly (and both
the HOST and OTG phys).
On rk3228 the phy block has two supplying clocks for 1 OTG and 3 HOSTs (and I
haven't been able to figure out which is supplying which usb block yet)
etc.
> usb_otg: usb@1018 {
> compatible = "rockchip,rk3288-usb", "rockchip,rk3066-usb",
> "snps,dwc2";
you probably want something like
compatible = "rockchip,rk3036-usb", "rockchip
Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
On 12/16/15 14:17, tiffany lin wrote:
> Hi Hans,
>
>
> On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
>>
>> On 12/15/15 14:51, tiffany lin wrote:
>>> We are not familiar with v4l2-compliance utility, we will check how to
>>> use it.
>>
>> It's part of v4l-utils.git (http://git.linuxtv.org/v4l-utils.git/). There is
>> a
>> fairly decent man page. It does exhaustive compliance tests for V4L2 devices.
>>
>> That said, the support for memory-to-memory codec devices is not great, so I
>> wouldn't
>> trust any failures it reports when using the streaming tests (i.e. the
>> --stream*
>> options). By default just run 'v4l2-compliance -d /dev/videoX' to do the
>> compliance
>> test.
>>
>> Note: before I accept this driver I do want to see that compliance test
>> output!
>>
> Got it. We will provide it in next version.
> Now our driver is developed and run base on kernel v3.18.
> V4L2 and vb2 have some difference between Linux 4.4-rc1 and 3.18 kernel.
> Is it ok we provided test output base on v3.18 or we need to base on
> 4.4-rc1?
I'm actually not sure if the latest v4l2-compliance test suite will work with a
3.18
kernel. so either you have to go back to an older version of v4l2-compliance
that
works with 3.18 (go back to commit 4a57509a8334aca6ca8e81cd3beb08d5be397dac,
that
might do the trick) or (and that's what I recommend) go with the latest kernel.
For the media tree that is http://git.linuxtv.org/media_tree.git/log/.
The final version of the patch has to be against that kernel anyway.
> +}
> +
> +int m2mctx_venc_queue_init(void *priv, struct vb2_queue *src_vq,
> +struct vb2_queue *dst_vq)
> +{
> + struct mtk_vcodec_ctx *ctx = priv;
> + int ret;
> +
> + src_vq->type= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> + src_vq->io_modes= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
You're using videobuf2-dma-contig, so VB2_USERPTR is generally useless in
that
case. I would drop it.
>>> Sorry, I don't get it.
>>> We are using videobuf2-dma-contig, but we also using VB2_USERPTR.
>>
>> In that case the user pointer you pass in must point to physically
>> contiguous
>> memory. Which means you got it through some magic. Typically what should be
>> used
>> are dmabuf handles to pass buffers around between different subsystems.
>>
>> The use of VB2_USERPTR for that purpose is deprecated.
>>
>> Or am I misunderstanding you as well?
>>
> Our encoder support all three modes.
> In case that A driver + Encode driver flow, OUTPUT buffer will be
> VB2_DMABUF from A driver.
> In case that read YCbCr frame data from file and encode them to bit
> stream flow, we use VB2_USERPTR and VB2_MMAP.
> In VB2_USERPTR case, videobuf2-dma-contig will help us get continuous
> dma address.
> Our chip has IOMMU and M4U that help us get continuous phy address for
> encode HW.
>
> http://lists.infradead.org/pipermail/linux-mediatek/2015-October/002525.html
Ah, OK. Have you tested this with malloc()ed buffers? Just asking :-)
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] devicetree: sound: add binding for WM8974 codec
On Wed, Dec 16, 2015 at 01:31:30PM +, Måns Rullgård wrote: > This is the 1/1 you were missing. I need the patch in a form I can apply. > Am I the only one who is annoyed by scripts/get_maintainer.pl not > returning all the addresses it should in cases like this? Is there some > trick I'm missing? You can't blindly rely on get_maintainers, it's prone to both false positives (CCing too many people, especially if you enable git matching when it often starts spamming people who are just doing global cleanups) and false negatives (if you don't enable git matching and it misses people who care about a specific driver). signature.asc Description: PGP signature
Re: [PATCH 1/2] devicetree: sound: add binding for WM8974 codec
Mark,
This is the 1/1 you were missing.
Am I the only one who is annoyed by scripts/get_maintainer.pl not
returning all the addresses it should in cases like this? Is there some
trick I'm missing?
Mans Rullgard writes:
> This adds a binding for the Wolfson WM8974 mono audio codec.
>
> Signed-off-by: Mans Rullgard
> ---
> The Linux driver for this device currently only supports I2C, but SPI
> could easily be added if necessary, and DT bindings are supposed to be
> generic.
> ---
> Documentation/devicetree/bindings/sound/wlf,wm8974.txt | 15 +++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
> b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
> new file mode 100644
> index 000..01d3a7c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
> @@ -0,0 +1,15 @@
> +WM8974 audio CODEC
> +
> +This device supports both I2C and SPI (configured with pin strapping
> +on the board).
> +
> +Required properties:
> + - compatible: "wlf,wm8974"
> + - reg: the I2C address or SPI chip select number of the device
> +
> +Examples:
> +
> +codec: wm8974@1a {
> + compatible = "wlf,wm8974";
> + reg = <0x1a>;
> +};
> --
> 2.6.3
>
--
Måns Rullgård
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/3] arm64: dts: mt8173: Add dynamic power node.
This device node is for calculating dynamic power in mW.
Since mt8173 has two clusters, there are two dynamic power
coefficient as well.
Signed-off-by: Dawei Chien
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index c962d94..b6f4ea5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -71,6 +71,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <263>;
};
cpu1: cpu@1 {
@@ -95,6 +96,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <263>;
};
cpu2: cpu@100 {
@@ -119,6 +121,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <530>;
};
cpu3: cpu@101 {
@@ -143,6 +146,7 @@
#cooling-cells = <2>;
#cooling-min-level = <0>;
#cooling-max-level = <7>;
+ dynamic-power-coefficient = <530>;
};
idle-states {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/3] thermal: mediatek: Add cpu dynamic power cooling model.
MT8173 cpufreq driver select of_cpufreq_power_cooling_register registering
cooling devices with dynamic power coefficient.
Signed-off-by: Dawei Chien
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/17/251
---
drivers/cpufreq/mt8173-cpufreq.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
index 83001dc..d00bab5 100644
--- a/drivers/cpufreq/mt8173-cpufreq.c
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -263,17 +263,24 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy
*policy,
return 0;
}
+#define DYNAMIC_POWER "dynamic-power-coefficient"
+
static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
{
struct mtk_cpu_dvfs_info *info = policy->driver_data;
struct device_node *np = of_node_get(info->cpu_dev->of_node);
+ u32 capacitance = 0;
if (WARN_ON(!np))
return;
if (of_find_property(np, "#cooling-cells", NULL)) {
- info->cdev = of_cpufreq_cooling_register(np,
-policy->related_cpus);
+ of_property_read_u32(np, DYNAMIC_POWER, &capacitance);
+
+ info->cdev = of_cpufreq_power_cooling_register(np,
+ policy->related_cpus,
+ capacitance,
+ NULL);
if (IS_ERR(info->cdev)) {
dev_err(info->cpu_dev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/3] arm64: dts: mt8173: Add thermal zone node.
This adds thermal zone node to Mediatek MT8173 dtsi file.
Signed-off-by: Dawei Chien
---
This patch is base on patchset:
https://lkml.org/lkml/2015/11/30/239
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index fda805d..c962d94 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -188,6 +188,49 @@
clock-output-names = "cpum_ck";
};
+ thermal-zones {
+ cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ thermal-sensors = <&thermal>;
+ sustainable-power = <1500>; /* milliwatts */
+
+ trips {
+ threshold: trip-point@0 {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ target: trip-point@1 {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cpu_crit: cpu_crit@0 {
+ temperature = <115000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map@0 {
+ trip = <&target>;
+ cooling-device = <&cpu0 0 0>;
+ contribution = <1024>;
+ };
+ map@1 {
+ trip = <&target>;
+ cooling-device = <&cpu2 0 0>;
+ contribution = <2048>;
+ };
+ };
+ };
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/3] thermal: mediatek: Add cpu dynamic power cooling model.
Use Intelligent Power Allocation (IPA) technical to add dynamic power model for binding CPU thermal zone. The power allocator governor allocates power budget to control CPU temperature. Power Allocator governor is able to keep SOC temperature within a defined temperature range to avoid SOC overheat and keep it's performance. mt8173-cpufreq.c need to register its' own power model with power allocator thermal governor, so that power allocator governor can allocates suitable power budget to control CPU temperature. Binding document is refer to this patchset https://lkml.org/lkml/2015/11/30/239 Change since V5: 1. Remove thermal sensor ID from phandles Change since V4: 1. Remove unnecessary error-checking for mt8173-cpufreq.c 2. Initializing variable capacitance with 0 Change since V3: 1. Remove static power model 2. Split V3's device tree in two for thermal zones and dynamic power models respectively Change since V2: 1. Move dynamic/static power model in device tree Change since V1: 1. Include mt8171.h and sort header file for mt8173.dtsi Dawei Chien (3): thermal: mediatek: Add cpu dynamic power cooling model. arm64: dts: mt8173: Add thermal zone node. arm64: dts: mt8173: Add dynamic power node. arch/arm64/boot/dts/mediatek/mt8173.dtsi | 47 ++ drivers/cpufreq/mt8173-cpufreq.c | 12 ++-- 2 files changed, 57 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
Hi Hans,
On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
>
> On 12/15/15 14:51, tiffany lin wrote:
> > Hi Hans,
> >
> > Thanks for your time.
> >
> > On Mon, 2015-12-14 at 13:50 +0100, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> My apologies for the long delay, but I finally have time to do a review of
> >> this
> >> code.
> >>
> >> On 12/11/2015 10:55 AM, Tiffany Lin wrote:
> >>> From: Andrew-CT Chen
> >>>
> >>> Add v4l2 layer encoder driver for MT8173
> >>>
> >>> Signed-off-by: Tiffany Lin
> >>> ---
> >>> drivers/media/platform/Kconfig | 11 +
> >>> drivers/media/platform/Makefile|2 +
> >>> drivers/media/platform/mtk-vcodec/Makefile |8 +
> >>> drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 412 +
> >>> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1670
> >>>
> >>> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h | 45 +
> >>> .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 469 ++
> >>> .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 122 ++
> >>> .../media/platform/mtk-vcodec/mtk_vcodec_intr.c| 102 ++
> >>> .../media/platform/mtk-vcodec/mtk_vcodec_intr.h| 29 +
> >>> drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h | 26 +
> >>> .../media/platform/mtk-vcodec/mtk_vcodec_util.c| 106 ++
> >>> .../media/platform/mtk-vcodec/mtk_vcodec_util.h| 85 +
> >>> drivers/media/platform/mtk-vcodec/venc_drv_base.h | 62 +
> >>> drivers/media/platform/mtk-vcodec/venc_drv_if.c| 102 ++
> >>> drivers/media/platform/mtk-vcodec/venc_drv_if.h| 174 ++
> >>> drivers/media/platform/mtk-vcodec/venc_ipi_msg.h | 212 +++
> >>> 17 files changed, 3637 insertions(+)
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
> >>> create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h
> >>>
> >>
> >>
> >>
> >>> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >>> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >>> new file mode 100644
> >>> index 000..d59064d
> >>> --- /dev/null
> >>> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> >>> @@ -0,0 +1,1670 @@
> >>> +/*
> >>> +* Copyright (c) 2015 MediaTek Inc.
> >>> +* Author: PC Chen
> >>> +* Tiffany Lin
> >>> +*
> >>> +* This program is free software; you can redistribute it and/or modify
> >>> +* it under the terms of the GNU General Public License version 2 as
> >>> +* published by the Free Software Foundation.
> >>> +*
> >>> +* This program is distributed in the hope that it will be useful,
> >>> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> >>> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >>> +* GNU General Public License for more details.
> >>> +*/
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +#include "mtk_vcodec_drv.h"
> >>> +#include "mtk_vcodec_enc.h"
> >>> +#include "mtk_vcodec_intr.h"
> >>> +#include "mtk_vcodec_util.h"
> >>> +#include "venc_drv_if.h"
> >>> +
> >>> +static void mtk_venc_worker(struct work_struct *work);
> >>> +
> >>> +static struct mtk_video_fmt mtk_video_formats[] = {
> >>> + {
> >>> + .name = "4:2:0 3 Planes Y/Cb/Cr",
> >>
> >> Don't add the name. The v4l2 core will set that for you. This ensures that
> >> the name is
> >> always the same for the format, instead of being driver dependent.
> >>
> > We will remove it in next version.
> >
> >>> + .fourcc = V4L2_PIX_FMT_YUV420,
> >>> + .type = MTK_FMT_FRAME,
> >>> + .num_planes = 3,
> >>> + },
> >>> + {
> >>> + .name = "4:2:0 3 Planes Y/Cr/Cb",
> >>> + .fourcc = V4L2_PIX_FMT_YVU420,
> >>> + .type = MTK_FMT_FRAME,
> >>> + .num_planes = 3,
> >>> + },
> >>> + {
> >>> + .name = "4:2:0 2 Planes Y/CbCr",
> >>> + .fourcc = V4L2_PIX_FMT_NV12,
> >>>
[PATCH 1/2] devicetree: sound: add binding for WM8974 codec
This adds a binding for the Wolfson WM8974 mono audio codec.
Signed-off-by: Mans Rullgard
---
The Linux driver for this device currently only supports I2C, but SPI
could easily be added if necessary, and DT bindings are supposed to be
generic.
---
Documentation/devicetree/bindings/sound/wlf,wm8974.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.txt
diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
new file mode 100644
index 000..01d3a7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/wlf,wm8974.txt
@@ -0,0 +1,15 @@
+WM8974 audio CODEC
+
+This device supports both I2C and SPI (configured with pin strapping
+on the board).
+
+Required properties:
+ - compatible: "wlf,wm8974"
+ - reg: the I2C address or SPI chip select number of the device
+
+Examples:
+
+codec: wm8974@1a {
+ compatible = "wlf,wm8974";
+ reg = <0x1a>;
+};
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: lpc4337-ciaa: enable SCT-PWM
Joachim,
El 14/12/15 a las 19:48, Joachim Eastwood escribió:
> Hi Ariel,
>
> Sorry for the late reply. I have just started to put together my DT
> for 4.5 branch now.
>
> On 25 November 2015 at 13:28, Ariel D'Alessandro
> wrote:
>> (+To: Joachim)
>>
>> El 23/11/15 a las 09:37, Ariel D'Alessandro escribió:
>>> Enable the PWM based on the State Configurable Timer (SCT) included in
>>> the LPC4337 SoC of the CIAA-NXP board.
>>>
>>> Signed-off-by: Ariel D'Alessandro
>>> ---
>>> arch/arm/boot/dts/lpc4337-ciaa.dts | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> b/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> index 03bdf77..1a23589 100644
>>> --- a/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> +++ b/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> @@ -170,6 +170,10 @@
>>> pinctrl-0 = <&enet_rmii_pins>;
>>> };
>>>
>>> +&sct_pwm {
>>> + status = "okay";
>>> +};
>>> +
>
> Isn't this a bit useless without any pinmux setup?
Yes, it might be kind of useless. Do you think it shouldn't be enabled then?
--
Ariel D'Alessandro, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: lpc4337-ciaa: enable EEPROM memory
Joachim,
El 14/12/15 a las 19:52, Joachim Eastwood escribió:
> Hi Ariel,
>
> On 25 November 2015 at 13:28, Ariel D'Alessandro
> wrote:
>> (+To: Joachim)
>>
>> El 23/11/15 a las 09:37, Ariel D'Alessandro escribió:
>>> The CIAA-NXP board has a NXP LPC4337 SoC that includes a 16 KiB
>>> EEPROM memory.
>>>
>>> Signed-off-by: Ariel D'Alessandro
>>> ---
>>> arch/arm/boot/dts/lpc4337-ciaa.dts | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> b/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> index 5f500c1..03bdf77 100644
>>> --- a/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> +++ b/arch/arm/boot/dts/lpc4337-ciaa.dts
>>> @@ -155,6 +155,10 @@
>>> };
>>> };
>>>
>>> +&eeprom {
>>> + status = "okay";
>>> +};
>>> +
>
> I already had a patch that enabled the eeprom for all boards that
> included the lpc4357.dtsi from when I tested your driver. So opted to
> use that patch instead of this one. This is really a SoC device
> feature that doesn't require any board resources so I think it is
> better to have this entry in lpc4357.dtsi.
Yeah, you're right. Fine for me, thanks.
--
Ariel D'Alessandro, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
