* Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Young @ 2017-01-10 17:23 UTC (permalink / raw)
To: Sean Wang
Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1484056789.4057.17.camel@mtkswgap22>
Hi Sean,
The driver is looking very good, we are looking at minor details now.
On Tue, Jan 10, 2017 at 09:59:49PM +0800, Sean Wang wrote:
> On Tue, 2017-01-10 at 11:09 +0000, Sean Young wrote:
>
> > > +#include <linux/clk.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/reset.h>
> > > +#include <media/rc-core.h>
> > > +
> > > +#define MTK_IR_DEV KBUILD_MODNAME
> >
> > You could remove this #define and just use KBUILD_MODNAME
>
> I preferred to use MTK_IR_DEV internally that helps
> renaming in the future if necessary.
ok.
> >
> > > +
> > > +/* Register to enable PWM and IR */
> > > +#define MTK_CONFIG_HIGH_REG 0x0c
> > > +/* Enable IR pulse width detection */
> > > +#define MTK_PWM_EN BIT(13)
> > > +/* Enable IR hardware function */
> > > +#define MTK_IR_EN BIT(0)
> > > +
> > > +/* Register to setting sample period */
> > > +#define MTK_CONFIG_LOW_REG 0x10
> > > +/* Field to set sample period */
> > > +#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
> > > + MTK_IR_CLK_PERIOD)
> > > +#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> > > +#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
> > > +
> > > +/* Register to clear state of state machine */
> > > +#define MTK_IRCLR_REG 0x20
> > > +/* Bit to restart IR receiving */
> > > +#define MTK_IRCLR BIT(0)
> > > +
> > > +/* Register containing pulse width data */
> > > +#define MTK_CHKDATA_REG(i) (0x88 + 4 * (i))
> > > +#define MTK_WIDTH_MASK (GENMASK(7, 0))
> > > +
> > > +/* Register to enable IR interrupt */
> > > +#define MTK_IRINT_EN_REG 0xcc
> > > +/* Bit to enable interrupt */
> > > +#define MTK_IRINT_EN BIT(0)
> > > +
> > > +/* Register to ack IR interrupt */
> > > +#define MTK_IRINT_CLR_REG 0xd0
> > > +/* Bit to clear interrupt status */
> > > +#define MTK_IRINT_CLR BIT(0)
> > > +
> > > +/* Maximum count of samples */
> > > +#define MTK_MAX_SAMPLES 0xff
> > > +/* Indicate the end of IR message */
> > > +#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
> > > +/* Number of registers to record the pulse width */
> > > +#define MTK_CHKDATA_SZ 17
> > > +/* Source clock frequency */
> > > +#define MTK_IR_BASE_CLK 273000000
> > > +/* Frequency after IR internal divider */
> > > +#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
>
> > > +static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
> > > +{
> > > + struct mtk_ir *ir = dev_id;
> > > + u8 wid = 0;
> > > + u32 i, j, val;
> > > + DEFINE_IR_RAW_EVENT(rawir);
> > > +
> > > + mtk_irq_disable(ir, MTK_IRINT_EN);
> >
> > The kernel guarantees that calls to the interrupt handler are serialised,
> > no need to disable the interrupt in the handler.
>
> agreed. I will save the mtk irq disable/enable and retest again.
>
>
> > > +
> > > + /* Reset decoder state machine */
> > > + ir_raw_event_reset(ir->rc);
> >
> > Not needed.
>
>
> two reasons I added the line here
>
> 1)
> I thought it is possible the decoder goes to the
> middle state when getting the data not belonged
> to the protocol. If so, that would cause the decoding
> fails in the next time receiving the valid protocol data.
The last IR event submitted will always be a long space, that's enough
to reset the decoders. Adding a ir_raw_event_reset() will do this
more explicitly, rather than their state machines resetting themselves
through the trailing space.
> 2)
> the mtk hardware register always contains the start of
> IR message. So force to sync the state between
> HW and ir-core.
>
>
>
> > > +
> > > + /* First message must be pulse */
> > > + rawir.pulse = false;
> >
> > pulse = true?
>
> becasue of rawir.pulse = !rawir.pulse does as below
> so the initial value is set as false.
Ah, sorry, of course. :)
> > > +
> > > + /* Handle all pulse and space IR controller captures */
> > > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > > +
> > > + for (j = 0 ; j < 4 ; j++) {
> > > + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> > > + rawir.pulse = !rawir.pulse;
> > > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > > + }
> >
> > In v1 you would break out of the loop if the ir message was shorter, but
> > now you are always passing on 68 pulses and spaces. Is that right?
>
> as I asked in the previous mail list as below i copied from it, so i
> made some changes ...
>
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> > I had another question. I found multiple and same IR messages being
> > received when using SONY remote controller. Should driver needs to
> > report each message or only one of these to the upper layer ?
>
> In general the driver shouldn't try to change any IR message, this
> should be done in rc-core if necessary.
>
> rc-core should handle this correctly. If the same key is received twice
> within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
> layer.
> """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
> for example:
> the 68 pulse/spaces might contains 2.x IR messages when I
> pressed one key on SONY remote control.
>
> the v1 proposed is passing only one IR message into ir-core ;
> the v2 done is passing all IR messages even including the last
> incomplete message into ir-core.
Yes, agreed. Sorry if I wasn't clear. I just wanted to make sure you've
thought about what happens when the IR message is short (e.g. rc-5 with
23 pulse-spaces). Are the remaining registers 0 or do we get stale data
from a previous transmit?
> But I was still afraid the state machine can't go back to initial state
> after receiving these incomplete data.
>
> So the ir_raw_event_reset() call in the beginning of ISR seems becoming
> more important.
>
> > > + }
> > > +
> > > + /* The maximum number of edges the IR controller can
> > > + * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
> > > + * is over the limit, the last incomplete IR message would
> > > + * be appended trailing space and still would be sent into
> > > + * ir-rc-raw to decode. That helps it is possible that it
> > > + * has enough information to decode a scancode even if the
> > > + * trailing end of the message is missing.
> > > + */
> > > + if (!MTK_IR_END(wid, rawir.pulse)) {
> > > + rawir.pulse = false;
> > > + rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > > + }
See here you add a long space if one was not added already.
> > > +
> > > + ir_raw_event_handle(ir->rc);
> > > +
> > > + /* Restart controller for the next receive */
> > > + mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
> > > +
> > > + /* Clear interrupt status */
> > > + mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
> > > +
> > > + /* Enable interrupt */
> > > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > > +
> > > + return IRQ_HANDLED;
> > > +}
> > > +
> > > +static int mtk_ir_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = &pdev->dev;
> > > + struct device_node *dn = dev->of_node;
> > > + struct resource *res;
> > > + struct mtk_ir *ir;
> > > + u32 val;
> > > + int ret = 0;
> > > + const char *map_name;
> > > +
> > > + ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
> > > + if (!ir)
> > > + return -ENOMEM;
> > > +
> > > + ir->dev = dev;
> > > +
> > > + if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
> > > + return -ENODEV;
> > > +
> > > + ir->clk = devm_clk_get(dev, "clk");
> > > + if (IS_ERR(ir->clk)) {
> > > + dev_err(dev, "failed to get a ir clock.\n");
> > > + return PTR_ERR(ir->clk);
> > > + }
> > > +
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > + ir->base = devm_ioremap_resource(dev, res);
> > > + if (IS_ERR(ir->base)) {
> > > + dev_err(dev, "failed to map registers\n");
> > > + return PTR_ERR(ir->base);
> > > + }
> > > +
> > > + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> > > + if (!ir->rc) {
> > > + dev_err(dev, "failed to allocate device\n");
> > > + return -ENOMEM;
> > > + }
> > > +
> > > + ir->rc->priv = ir;
> > > + ir->rc->input_name = MTK_IR_DEV;
> > > + ir->rc->input_phys = MTK_IR_DEV "/input0";
> > > + ir->rc->input_id.bustype = BUS_HOST;
> > > + ir->rc->input_id.vendor = 0x0001;
> > > + ir->rc->input_id.product = 0x0001;
> > > + ir->rc->input_id.version = 0x0001;
> > > + map_name = of_get_property(dn, "linux,rc-map-name", NULL);
> > > + ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
> > > + ir->rc->dev.parent = dev;
> > > + ir->rc->driver_name = MTK_IR_DEV;
> > > + ir->rc->allowed_protocols = RC_BIT_ALL;
> > > + ir->rc->rx_resolution = MTK_IR_SAMPLE;
> > > + ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > > +
> > > + ret = devm_rc_register_device(dev, ir->rc);
> >
> > Here you do devm_rc_register_device()
>
> does it have problem ?
Sorry, no. I just wanted to highlight wrt a comment below.
>
>
> > > + if (ret) {
> > > + dev_err(dev, "failed to register rc device\n");
> > > + return ret;
> > > + }
> > > +
> > > + platform_set_drvdata(pdev, ir);
> > > +
> > > + ir->irq = platform_get_irq(pdev, 0);
> > > + if (ir->irq < 0) {
> > > + dev_err(dev, "no irq resource\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + /* Enable interrupt after proper hardware
> > > + * setup and IRQ handler registration
> > > + */
> > > + if (clk_prepare_enable(ir->clk)) {
> > > + dev_err(dev, "try to enable ir_clk failed\n");
> > > + ret = -EINVAL;
> > > + goto exit_clkdisable_clk;
> > > + }
> > > +
> > > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > > +
> > > + ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
> > > + if (ret) {
> > > + dev_err(dev, "failed request irq\n");
> > > + goto exit_clkdisable_clk;
> > > + }
> > > +
> > > + /* Enable IR and PWM */
> > > + val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
> > > + val |= MTK_PWM_EN | MTK_IR_EN;
> > > + mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
> > > +
> > > + /* Setting sample period */
> > > + mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
> > > + MTK_CONFIG_LOW_REG);
> > > +
> > > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > > +
> > > + dev_info(dev, "Initialized MT7623 IR driver, sample period = %luus\n",
> > > + DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
> > > +
> > > + return 0;
> > > +
> > > +exit_clkdisable_clk:
> > > + clk_disable_unprepare(ir->clk);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int mtk_ir_remove(struct platform_device *pdev)
> > > +{
> > > + struct mtk_ir *ir = platform_get_drvdata(pdev);
> > > +
> > > + /* Avoid contention between remove handler and
> > > + * IRQ handler so that disabling IR interrupt and
> > > + * waiting for pending IRQ handler to complete
> > > + */
> > > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > > + synchronize_irq(ir->irq);
> > > +
> > > + clk_disable_unprepare(ir->clk);
> > > +
> > > + rc_unregister_device(ir->rc);
> >
> > Yet here you explicitly call rc_unregister_device(). Since it was registered
> > with the devm call, this call is not needed and will lead to double frees etc
>
> bug :( . I will fix it ..
>
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static const struct of_device_id mtk_ir_match[] = {
> > > + { .compatible = "mediatek,mt7623-cir" },
> > > + {},
> > > +};
> > > +MODULE_DEVICE_TABLE(of, mtk_ir_match);
> > > +
> > > +static struct platform_driver mtk_ir_driver = {
> > > + .probe = mtk_ir_probe,
> > > + .remove = mtk_ir_remove,
> > > + .driver = {
> > > + .name = MTK_IR_DEV,
> > > + .of_match_table = mtk_ir_match,
> > > + },
> > > +};
> > > +
> > > +module_platform_driver(mtk_ir_driver);
> > > +
> > > +MODULE_DESCRIPTION("Mediatek IR Receiver Controller Driver");
> > > +MODULE_AUTHOR("Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>");
> > > +MODULE_LICENSE("GPL");
> > > --
> > > 2.7.4
> > >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
From: Fabio Estevam @ 2017-01-10 17:28 UTC (permalink / raw)
To: Andrey Smirnov
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Russell King, linux-kernel, Rob Herring, Sascha Hauer,
Fabio Estevam, Shawn Guo, yurovsky-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170110163015.22444-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jan 10, 2017 at 2:30 PM, Andrey Smirnov
<andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> ENABLE_LINREG bit is implemented by 3P0, 1P1 and 2P5 regulators on
> i.MX6. This property is present in similar code in Fresscale BSP and
> made its way upstream in imx6ul.dtsi, so this patch adds this property
> to the rest of i.MX6 family for completness.
Please see:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/arch/arm/boot/dts/imx6ul.dtsi?id=27958ccdf29e9971732e02494b48be54b0691269
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/11] dmaengine: cppi41: rename platform variables
From: Sergei Shtylyov @ 2017-01-10 17:35 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-2-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hello!
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> Currently, only the am335x is supported by the driver.
> Though the driver has a glue layer to support different platforms,
> some platform variable names are not prefixed with the platform name.
> To facilitate the addition of a new platform,
> rename some variables owned by the am335x glue.
>
> Currently, only the am335x is supported by the driver.
> Though the driver provide a glue layer that should be used to support
> another platforms. Rename variable specifics to the am335x glue.
You are repeating yourself. :-)
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/3] arm64: dts: exynos: Fix DTC warnings for Exynos boards
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
Hello Krzysztof,
This trivial series contains fixes for DTC warnings caused by mismatches
between unit names and reg properties in device tree nodes.
The patches shouldn't cause a functional change but have been just build
tested. I compared the generated DTB though to make sure that only these
nodes changed.
Best regards,
Javier
Changes since v1:
- Fix subject line since I forgot the "exynos" prefix.
Javier Martinez Canillas (3):
arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
arm64: dts: exynos: Add missing unit name to Exynos5433 SoC node
arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Javier Martinez Canillas, Catalin Marinas, Will Deacon,
Andi Shyti, Chanwoo Choi, Kukjin Kim, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 80aa60e38237..0d2fedc6ac2f 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -69,7 +69,7 @@
method = "smc";
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: exynos: Add missing unit name to Exynos5433 SoC node
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e5851c..3695ddaf2e04 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -241,7 +241,7 @@
mask = <0x1>;
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Javier Martinez Canillas @ 2017-01-10 17:38 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
The "samsung,exynos5433-mipi-video-phy" and "samsung,exynos5250-dwusb3"
DT bindings don't specify a reg property for these nodes, so having a
unit name leads to the following DTC warnings:
Node /soc/video-phy@105c0710 has a unit name, but no reg property
Node /soc/usb@15400000 has a unit name, but no reg property
Node /soc/usb@15a00000 has a unit name, but no reg property
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 3695ddaf2e04..17e5dafd392c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -706,7 +706,7 @@
interrupts = <GIC_PPI 9 0xf04>;
};
- mipi_phy: video-phy@105c0710 {
+ mipi_phy: video-phy {
compatible = "samsung,exynos5433-mipi-video-phy";
#phy-cells = <1>;
samsung,pmu-syscon = <&pmu_system_controller>;
@@ -1285,7 +1285,7 @@
status = "disabled";
};
- usbdrd30: usb@15400000 {
+ usbdrd30: usb-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
<&cmu_fsys CLK_SCLK_USBDRD30>;
@@ -1332,7 +1332,7 @@
status = "disabled";
};
- usbhost30: usb@15a00000 {
+ usbhost30: usb-1 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBHOST30>,
<&cmu_fsys CLK_SCLK_USBHOST30>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 02/11] dmaengine: cppi41: Split out the interrupt handler
From: Sergei Shtylyov @ 2017-01-10 17:39 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-3-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hello.
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> The current interrupt handler do some actions specifics to am335x.
> These actions should be made by the platform interrupt handler.
> Split out the interrupt handler in two:
> one for the am335x platform and a generic one.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/dma/cppi41.c | 24 +++++++++++++++---------
> 1 file changed, 15 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index 25ee71d..42744ed 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
> @@ -284,18 +284,11 @@ static u32 cppi41_pop_desc(struct cppi41_dd *cdd, unsigned queue_num)
> return desc;
> }
>
> -static irqreturn_t cppi41_irq(int irq, void *data)
> +static irqreturn_t cppi41_irq(struct cppi41_dd *cdd)
> {
> - struct cppi41_dd *cdd = data;
> struct cppi41_channel *c;
> - u32 status;
> int i;
>
> - status = cppi_readl(cdd->usbss_mem + USBSS_IRQ_STATUS);
> - if (!(status & USBSS_IRQ_PD_COMP))
> - return IRQ_NONE;
> - cppi_writel(status, cdd->usbss_mem + USBSS_IRQ_STATUS);
> -
I fail to understand why non-CPPI 4.1 regs are used here (and that
positioning itself as an "abstract" CPPI 4.1 driver).
[...]
> @@ -351,6 +344,19 @@ static irqreturn_t cppi41_irq(int irq, void *data)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t am335x_cppi41_irq(int irq, void *data)
> +{
> + struct cppi41_dd *cdd = data;
> + u32 status;
> +
> + status = cppi_readl(cdd->usbss_mem + USBSS_IRQ_STATUS);
> + if (!(status & USBSS_IRQ_PD_COMP))
> + return IRQ_NONE;
> + cppi_writel(status, cdd->usbss_mem + USBSS_IRQ_STATUS);
> +
> + return cppi41_irq(cdd);
> +}
> +
IMHO this stuff just needs to move to the MUSB glue.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
From: Benjamin Herrenschmidt @ 2017-01-10 17:41 UTC (permalink / raw)
To: Guenter Roeck, Edward James
Cc: andrew, corbet, devicetree, eajames.ibm, jdelvare, joel,
linux-doc, linux-hwmon, linux-i2c, linux-kernel, mark.rutland,
robh+dt, wsa
In-Reply-To: <8b182766-32a0-9eb1-7917-14abf811cef5@roeck-us.net>
On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote:
> > Instead of the "online" attribute, what do you think about using the
> > "bind"/"unbind" API to probe the device from user space once the system
> > is powered on? All the hwmon registration would take place in the probe
> > function, it would just occur some time after boot.
> >
>
> A more common approach would be to have a platform driver. That platform
> driver would need a means to detect if the OCC is up and running, and
> instantiate everything else once it is.
>
> A trigger from user space is problematic because there is no guarantee
> that the OCC is really up (or that it even exists).
>
> An alternative might be to have the hwmon driver poll for the OCC,
> but that would be a bit more difficult and might require a kernel thread
> or maybe asynchronous probing.
Hi Guenter !
I'm not sure I agree with you here ;-)
I'm don't know how much background you got (I missed the beginning of
the discussion) but basically this driver runs on the BMC (system
controller) of the POWER9 server, the OCC is inside the POWER9 chip
itself.
So the presence/power state of the OCC doesn't depend on the BMC
platform kernel code. The BMC userspace controls power up and down to the POWER9, and thus it's the one to know whether the remote is up.
If we were to create a "platform driver", all it would do is get input
from userspace exactly like that sysfs file :-)
So if you don't like the sysfs file that registers/de-registers, which
I sort-of understand, it's a bit of a hack (though a rather efficient
one), I think the bind/unbind approach makes sense. However, I wonder
whether the simplest and most efficient (remember this BMC has a really
slow CPU) is an "online" file sysfs file, though rather than
registering/de-registering the hwmon it would simply make it stop
accessing the HW (and return some known "offline" values).
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Mark Rutland @ 2017-01-10 17:43 UTC (permalink / raw)
To: Anurup M
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
catalin.marinas-5wv7dgnIgG8, arnd-r2nGTMty4D4,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, corbet-T1hC0tSOHrs,
will.deacon-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
anurup.m-hv44wF8Li93QT0dZR+AlfA,
zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaojun-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
sanil.kumar-C8/M+/jPZTeaMJb+Lgu22Q,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
shiju.jose-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, shyju.pv-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <1483339672-23778-1-git-send-email-anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Hi,
On Mon, Jan 02, 2017 at 01:47:52AM -0500, Anurup M wrote:
> ToDo:
> 1) The counter overflow handling is currently unsupported in this
> patch series.
>From a quick scan of the patches, I see mention of an interrupt in a
comment the driver, but there's noething in the DT binding.
Is there an overflow interrupt at all?
Or do you need to implement polling to avoid overflow?
This is a prerequisite for merging the driver.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
From: Benjamin Herrenschmidt @ 2017-01-10 17:45 UTC (permalink / raw)
To: Andrew Jeffery, Guenter Roeck, Edward James
Cc: corbet, devicetree, eajames.ibm, jdelvare, joel, linux-doc,
linux-hwmon, linux-i2c, linux-kernel, mark.rutland, robh+dt, wsa
In-Reply-To: <1483919532.2950.1.camel@aj.id.au>
On Mon, 2017-01-09 at 10:22 +1030, Andrew Jeffery wrote:
> Alternatively, in the style of your first para, we could push the
> host
> CPU state management into the kernel and expose a boot/reboot/power-
> off
> API to userspace. That would give us a place to hook calls for
> configuring and cleaning up any host-dependent drivers on the BMC.
That's nasty. Each machine has a subtly different way of controller
host power, that would mean a different kernel driver for each of them,
which we are trying to avoid.
This is userspace policy.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Mark Rutland @ 2017-01-10 17:45 UTC (permalink / raw)
To: Anurup M
Cc: Rob Herring, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
anurup.m-hv44wF8Li93QT0dZR+AlfA,
zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaojun-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
sanil.kumar-C8/M+/jPZTeaMJb+Lgu22Q,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
shiju.jose-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, shyju.pv-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <586DD28E.5050500-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Jan 05, 2017 at 10:28:54AM +0530, Anurup M wrote:
>
>
> On Wednesday 04 January 2017 04:26 AM, Rob Herring wrote:
> >On Mon, Jan 02, 2017 at 01:49:03AM -0500, Anurup M wrote:
> >>From: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>
> >>Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
> >>
> >>Signed-off-by: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>Signed-off-by: Anurup M <anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>---
> >> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
> >> 1 file changed, 41 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> >>
> >>diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> >>new file mode 100644
> >>index 0000000..bbe8b45
> >>--- /dev/null
> >>+++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> >>@@ -0,0 +1,41 @@
> >>+The Hisilicon Djtag is an independent component which connects with some other
> >>+components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
> >>+in the chip. The djtag controls access to connecting modules of CPU and IO
> >>+dies.
> >>+The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
> >>+are accessed by djtag during real time debugging. In IO die there are connecting
> >>+components like RSA. These components appear as devices attached to djtag bus.
> >>+
> >>+Hisilicon HiP05/06/07 djtag for CPU and IO die
> >>+Required properties:
> >>+ - compatible : The value should be as follows
> >>+ (a) "hisilicon,hip05-djtag-v1" for CPU and IO die which use v1 hw in
> >>+ HiP05 chipset.
> >You don't need to distinguish the CPU and IO blocks?
>
> The CPU and IO djtag nodes will have different base address(in reg
> property).
> There is no difference in handling of CPU and IO dies in the djtag driver.
> So there is currently no need to distinguish them.
It may still make sense to distinuguish them, even if the current djtag
driver can handle them the same. Presumably clients of the djtag driver
will poke CPU and IO djtag units differently.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH linux 2/6] hwmon: occ: Add sysfs interface
From: Guenter Roeck @ 2017-01-10 17:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Edward James, andrew, corbet, devicetree, eajames.ibm, jdelvare,
joel, linux-doc, linux-hwmon, linux-i2c, linux-kernel,
mark.rutland, robh+dt, wsa
In-Reply-To: <1484070104.21117.29.camel@kernel.crashing.org>
On Tue, Jan 10, 2017 at 11:41:44AM -0600, Benjamin Herrenschmidt wrote:
> On Sat, 2017-01-07 at 09:15 -0800, Guenter Roeck wrote:
> > > Instead of the "online" attribute, what do you think about using the
> > > "bind"/"unbind" API to probe the device from user space once the system
> > > is powered on? All the hwmon registration would take place in the probe
> > > function, it would just occur some time after boot.
> > >
> >
> > A more common approach would be to have a platform driver. That platform
> > driver would need a means to detect if the OCC is up and running, and
> > instantiate everything else once it is.
> >
> > A trigger from user space is problematic because there is no guarantee
> > that the OCC is really up (or that it even exists).
> >
> > An alternative might be to have the hwmon driver poll for the OCC,
> > but that would be a bit more difficult and might require a kernel thread
> > or maybe asynchronous probing.
>
> Hi Guenter !
>
> I'm not sure I agree with you here ;-)
>
> I'm don't know how much background you got (I missed the beginning of
> the discussion) but basically this driver runs on the BMC (system
> controller) of the POWER9 server, the OCC is inside the POWER9 chip
> itself.
>
> So the presence/power state of the OCC doesn't depend on the BMC
> platform kernel code. The BMC userspace controls power up and down to the POWER9, and thus it's the one to know whether the remote is up.
>
> If we were to create a "platform driver", all it would do is get input
> from userspace exactly like that sysfs file :-)
>
> So if you don't like the sysfs file that registers/de-registers, which
> I sort-of understand, it's a bit of a hack (though a rather efficient
> one), I think the bind/unbind approach makes sense. However, I wonder
> whether the simplest and most efficient (remember this BMC has a really
> slow CPU) is an "online" file sysfs file, though rather than
> registering/de-registering the hwmon it would simply make it stop
> accessing the HW (and return some known "offline" values).
>
I don't like that too much either; it still looks like a hack.
How about using bind/unbind then ?
Guenter
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Will Deacon @ 2017-01-10 17:52 UTC (permalink / raw)
To: Rob Clark
Cc: iommu@lists.linux-foundation.org, linux-arm-msm, Sricharan R,
Jordan Crouse, Mark Rutland, Rob Herring,
devicetree@vger.kernel.org
In-Reply-To: <CAF6AEGuUidGEONzh92SYg9V2gE812oq_0CoZt-Zv7=bzb3FN3A@mail.gmail.com>
Hi Rob,
On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
> On Thu, Jan 5, 2017 at 10:49 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote:
> >> I'm not sure if the better solution then would be to have two fault
> >> callbacks, one immediately from the IRQ and a later one from wq. Or
> >> let the driver handle the wq business and give it a way to tell the
> >> IOMMU when to resume.
> >>
> >> I kinda think we should punt on the worker thread for now until we are
> >> ready to resume faulting transactions, because I guess a strong chance
> >> that whatever way we do it now will be wrong ;-)
> >
> > I guess what I'm after is for you to change the interrupt handlers to be
> > threaded, like they are for SMMUv3. I *think* you can do that with a NULL
> > thread_fn for now, and just call report_iommu_fault from the handler.
> > The return value of that could, in theory, be used to queued the paging
> > request and wake the paging thread in future.
>
> If we only pass in the non-threaded irq fxn, I'm not really sure how
> that changes anything.. or maybe I'm not understanding what you mean.
>
> But yeah, I guess we could use request_threaded_irq() to get both IRQ
> context notification and a later thread context notification rather
> than doing the wq thing. Either way the iommu API has to change
> slightly.
>
> >> > I wonder if this should also be predicated on the compatible string, so
> >> > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
> >> > the compatible string isn't specific enough to identify an implementation
> >> > with the required SS behaviour? On the other hand, it feels pretty
> >> > redundant and a single "stalling works" property is all we need.
> >>
> >> We could also drop the property and key the behavior on specific
> >> compat strings I guess. Having both seems a bit odd. Anyways, I'll
> >> defer to DT folks about what the cleaner approach is.
> >
> > As Robin pointed out, we do need to be able to distinguish the integration
> > of the device from the device itself. For example, MMU-9000 might be capable
> > of stalling, but if it's bolted to a PCI RC, it's not safe to do so.
>
> Hmm, well we install the fault handler on the iommu_domain.. perhaps
> maybe a combo of dts property (or deciding based on more specific
> compat string), plus extra param passed in to
> iommu_set_fault_hander(). The dts property or compat string to
> indicate whether the iommu (and how it is wired up) can handle stalls,
> and enable_stall param when fault handler is registered to indicate
> whether the device itself can cope.. if either can't do stalling, then
> don't set CFCFG.
I thought about this some more, and I think you're right. Having
iommu_set_fault_handler take a flags parameter indicating that, for example,
the fault handler can deal with paging, is all we need to implement the
per-master opt-in functionality for stalling faults. There's no real
requirement to standardise a generic firmware property for that (but
we still need *something* that says stalling is usable on the SMMU --
perhaps just the compatible string is ok).
Taking this further, there's then no need for the threaded IRQ function
in the SMMUv2 driver after all. Instead, we pass a continuation function
pointer and opaque token from the SMMU driver to the fault handler in
IRQ context (this will be in thread context for SMMUv3, but that should
be fine). The fault handler can then stash these someplace, and signal
a wakeup for its own threaded handler, which ultimately calls the SMMU
continuation function with the opaque token as a parameter when it's done
with the fault. I think that's enough to get things rolling without adding
lots of infrastructure to the SMMU driver initially. If a pattern emerges
amongst users of the interface, then we could consolidate some of the work
handling back into IOMMU core.
What do you think? It should all be pretty straightforward for what you
want to do.
Will
^ permalink raw reply
* Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
From: Sergei Shtylyov @ 2017-01-10 17:53 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-9-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> The da8xx has a cppi41 dma controller.
It's called CPPI 4.1. :-)
> This is add the glue layer required to make it work on da8xx,
> as well some changes in driver (e.g to manage clock).
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/dma/cppi41.c | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 95 insertions(+)
>
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index 939398e..4318e53 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
[...]
> @@ -86,10 +87,19 @@
>
> #define USBSS_IRQ_PD_COMP (1 << 2)
>
> +/* USB DA8XX */
> +#define DA8XX_INTR_SRC_MASKED 0x38
> +#define DA8XX_END_OF_INTR 0x3c
> +
> +#define DA8XX_QMGR_PENDING_MASK (0xf << 24)
> +
> +
> +
One empty line is enough.
> /* Packet Descriptor */
> #define PD2_ZERO_LENGTH (1 << 19)
>
> #define AM335X_CPPI41 0
> +#define DA8XX_CPPI41 1
>
> struct cppi41_channel {
> struct dma_chan chan;
[...]
> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq, void *data)
> return cppi41_irq(cdd);
> }
>
> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
> +{
> + struct cppi41_dd *cdd = data;
> + u32 status;
> + u32 usbss_status;
> +
> + status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
> + if (status & DA8XX_QMGR_PENDING_MASK)
> + cppi41_irq(cdd);
> + else
> + return IRQ_NONE;
Seems correct...
> +
> + /* Re-assert IRQ if there no usb core interrupts pending */
> + usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
> + if (!usbss_status)
> + cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
I don't understand this...
> +
> + return IRQ_HANDLED;
> +}
> +
> static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
> {
> dma_cookie_t cookie;
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 09/11] dmaengine: cppi41: Fix a race between PM runtime and channel abort
From: Sergei Shtylyov @ 2017-01-10 17:55 UTC (permalink / raw)
To: Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <20170109160656.3470-10-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
> cppi41_dma_issue_pending() may be called while the device is runtime
> suspended. In that case, the descritpor will be push to the pending
"Descriptor" and "pushed".
> list and then be queued to hardware queue.
> But if cppi41_stop_chan() is called before the device got time to
> resume, then the descriptor will remain in the pending list and be
> queued to hardware queue after the teardown.
> During the channel stop, check if there is a pendding descriptor
Pending.
> and if so, remove it.
>
> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-2-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
> Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
> integrated DRAM, and several peripherals.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> ---
> Documentation/arm/sunxi/README | 4 ++++
> arch/arm/mach-sunxi/sunxi.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index cd0243302bc1..91ec8f2055be 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -67,6 +67,10 @@ SunXi family
> + Datasheet
> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
>
> + - Allwinner V3s (sun8i)
> + + Datasheet
> + https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
> +
Please don't put random links in there, but at least something that we
know will be there in a couple of weeks/monthes/years
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-10 18:10 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-3-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> V3s has a similar but cut-down CCU to H3.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
It looks like there's nothing different but the clocks that you
register with the H3, please just use the H3 driver.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 3/5] pinctrl: sunxi: add driver for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:18 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-4-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
On Tue, Jan 03, 2017 at 11:16:27PM +0800, Icenowy Zheng wrote:
> V3s SoC features only a pin controller (for the lack of CPUs part).
>
> Add a driver for this controller.
>
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/5] ARM: dts: sunxi: add dtsi file for V3s SoC
From: Maxime Ripard @ 2017-01-10 18:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170103151629.19447-5-icenowy-ymACFijhrKM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 338 bytes --]
On Tue, Jan 03, 2017 at 11:16:28PM +0800, Icenowy Zheng wrote:
> + uart0_pins_a: uart0@0 {
> + pins = "PB8", "PB9";
> + function = "uart0";
> + bias-pull-up;
Why do you need a pullup here?
Looks good otherwise.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6: Specify 'anatop-enable-bit' where appropriate
From: Andrey Smirnov @ 2017-01-10 18:24 UTC (permalink / raw)
To: Fabio Estevam
Cc: Mark Rutland, devicetree@vger.kernel.org, Russell King,
linux-kernel, Rob Herring, Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel@lists.infradead.org, Andrey Yurovsky
In-Reply-To: <CAOMZO5CnwrPcney0qzQgex_aFXCrksmEocZ28nf54Kvcm2dq-w@mail.gmail.com>
On Tue, Jan 10, 2017 at 9:28 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Jan 10, 2017 at 2:30 PM, Andrey Smirnov
> <andrew.smirnov@gmail.com> wrote:
>> ENABLE_LINREG bit is implemented by 3P0, 1P1 and 2P5 regulators on
>> i.MX6. This property is present in similar code in Fresscale BSP and
>> made its way upstream in imx6ul.dtsi, so this patch adds this property
>> to the rest of i.MX6 family for completness.
>
> Please see:
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/arch/arm/boot/dts/imx6ul.dtsi?id=27958ccdf29e9971732e02494b48be54b0691269
Fabio:
I submitted a patch implementing this property to LKML as well, see
https://www.spinics.net/lists/kernel/msg2418471.html
All of these patches are a part of a broader attempt to add PCIe
support for i.MX7, and on that platform this is a part of a 1P0D
regulator which supplies PCIe PHY.
I can rebase this patch set to take your commit into account, or else
let's discuss the best way to allow setting ENABLE_LINREG.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: clk: add rockchip, grf property for RK3399
From: Doug Anderson @ 2017-01-10 18:34 UTC (permalink / raw)
To: Xing Zheng
Cc: Mark Rutland, devicetree@vger.kernel.org, Heiko Stübner,
Michael Turquette, Stephen Boyd, linux-kernel@vger.kernel.org,
open list:ARM/Rockchip SoC..., Rob Herring, linux-clk,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1484028930-20305-3-git-send-email-zhengxing@rock-chips.com>
Hi,
On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> Add support for rockchip,grf property which is used for GRF muxes
> on RK3399.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v4:
> - update the decription for rockchip,grf property
>
> Changes in v3: None
> Changes in v2: None
>
> Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: exynos: Fix DTC warnings for Exynos boards
From: Krzysztof Kozlowski @ 2017-01-10 18:42 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Andi Shyti, Chanwoo Choi, devicetree, Kukjin Kim,
Catalin Marinas, linux-samsung-soc, Rob Herring, Will Deacon,
Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-1-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:29PM -0300, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> This trivial series contains fixes for DTC warnings caused by mismatches
> between unit names and reg properties in device tree nodes.
>
> The patches shouldn't cause a functional change but have been just build
> tested. I compared the generated DTB though to make sure that only these
> nodes changed.
>
> Best regards,
> Javier
>
> Changes since v1:
> - Fix subject line since I forgot the "exynos" prefix.
Thanks :)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Doug Anderson @ 2017-01-10 18:45 UTC (permalink / raw)
To: Xing Zheng
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Elaine Zhang, Heiko Stübner, Catalin Marinas, Shawn Lin,
Brian Norris, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, David Wu, Jianqun Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar Wang
In-Reply-To: <1484028930-20305-2-git-send-email-zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi,
On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
>
> Changes in v4:
> - separte the binding patch
>
> Changes in v3:
> - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
>
> Changes in v2:
> - referring pmugrf for PMUGRU
> - fix the typo "invaild" in COMMIT message
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
This seems fine to me, so:
Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
...but I will say that before you actually add any real "MUXGRF"
clocks on rk3399 you _might_ need to rework the code to make things
truly "optional". If it turns out that any existing clocks that
already exist today already go through one of these muxes in the GRF
and we've always been assuming one setting of the mux, we'll need to
make sure we keep assuming that setting of the mux even if the "grf"
isn't specified.
As I understand it, your motivation for this patch is to eventually be
able to model the EDP reference clock which can either be xin24 or
"edp osc". Presumably the eDP "reference clock" isn't related to any
of the pre-existing eDP clocks so that one should be safe.
-Doug
^ permalink raw reply
* [PATCH v2 0/2] iio: distance: srf08: add IIO driver for us ranger
From: Andreas Klinger @ 2017-01-10 18:47 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
trivial, mranostay, linux-i2c, devicetree
Cc: ak
This patch series adds IIO driver support for srf08 ultrasonic ranger
devices.
The first patch add a trivial device tree binding for the device together
with a new vendor devantech.
The second patch is the IIO driver which in turn is using I2C to talk to
the device.
Documentation about the sensor can be found here:
http://www.robot-electronics.co.uk/htm/srf08tech.html
Changes in v2:
Lots of updates thanks to Peters really fast review within 30 minutes
after first submission of the driver.
* Patch 2: "iio: distance: srf08: add IIO driver for us ranger"
- alphabetic order in Makefile
- use of u8 while accessing registers
- avoid endianness problems with 16 bit values
- missing return value checks
- some explaining documentation added
Andreas Klinger (2):
iio: distance: srf08: add trivial DT binding
iio: distance: srf08: add IIO driver for us ranger
.../devicetree/bindings/i2c/trivial-devices.txt | 1 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/proximity/Kconfig | 15 +
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/srf08.c | 362 +++++++++++++++++++++
5 files changed, 380 insertions(+)
create mode 100644 drivers/iio/proximity/srf08.c
--
2.1.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox