Re: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb
On Tue, Feb 10, 2015 at 05:10:04PM +0800, Zhangfei Gao wrote: Add usb phy controller for hi6220 platform Signed-off-by: Zhangfei Gao zhangfei@linaro.org --- drivers/usb/phy/Kconfig | 9 ++ drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-hi6220-usb.c | 306 +++ 3 files changed, 316 insertions(+) create mode 100644 drivers/usb/phy/phy-hi6220-usb.c diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index c6d0c8e..405a3d0 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -173,6 +173,15 @@ config USB_MXS_PHY MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x. +config USB_HI6220_PHY + tristate hi6220 USB PHY support + select USB_PHY + select MFD_SYSCON + help + Enable this to support the HISILICON HI6220 USB PHY. + + To compile this driver as a module, choose M here. + config USB_RCAR_PHY tristate Renesas R-Car USB PHY support depends on USB || USB_GADGET diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index 75f2bba..00172d3 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_SAMSUNG_USBPHY)+= phy-samsung-usb.o obj-$(CONFIG_TWL6030_USB)+= phy-twl6030-usb.o obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o obj-$(CONFIG_USB_GPIO_VBUS) += phy-gpio-vbus-usb.o +obj-$(CONFIG_USB_HI6220_PHY) += phy-hi6220-usb.o new drivers only on drivers/phy/, sorry. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 2/5] irqchip: add virtual demultiplexer implementation
On Thu, Jan 29, 2015 at 11:33:37AM +0100, Boris Brezillon wrote: +#ifdef CONFIG_VIRT_IRQ_DEMUX_CHIP +/** + * struct irq_chip_virt_demux - Dumb demultiplexer irq chip data structure s/Dumb/Virtual/ ? + * @domain: irq domain pointer + * @available: Bitfield of valid irqs + * @unmasked:Bitfield containing irqs status + * @flags: irq_virt_demux_flags flags + * @src_irq: irq feeding the virt demux chip + * + * Note, that irq_chip_generic can have multiple irq_chip_type + * implementations which can be associated to a particular irq line of + * an irq_chip_generic instance. That allows to share and protect + * state in an irq_chip_generic instance when we need to implement + * different flow mechanisms (level/edge) for it. This seems like a copy/paste from struct irq_chip_generic; it seems not relevant, seeing how irq_chip_virt_demux does not even have an irq_chip_type pointer list. Also, with a demuxer like this, we're bound to whatever flow type its host is, no? +# Dumb interrupt demuxer chip implementation s/Dumb/Virtual/ ? +#ifdef CONFIG_VIRT_IRQ_DEMUX_CHIP +/** + * handle_virt_demux_irq - Dumb demuxer irq handle function. idem + * @irq: the interrupt number + * @desc: the interrupt description structure for this irq + * + * Dumb demux interrupts are sent from a demultiplexing interrupt handler idem + * which is not able to decide which child interrupt handler should be + * called. + * + * Note: The caller is expected to handle the ack, clear, mask and + * unmask issues if necessary. + */ If we're calling multiple handlers, how can they all do this and not collide? Over all it looks good -- in as far as my (admittedly stale IRQ braincells) go. I'll go queue up these bits, if you could send me a delta patch addressing these 'minor' comment issues? -- 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 support for Fujitsu USB host controller
Hi 2015-01-31 0:38 GMT+08:00 Felipe Balbi ba...@ti.com: Hi, On Thu, Jan 29, 2015 at 10:23:12AM -0600, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 09:22:50AM -0600, Felipe Balbi wrote: Hi, On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeker Yeh wrote: These patches add support for XHCI compliant Host controller found on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver and last four patch is about quirk implementation of errata in Synopsis DesignWare USB3 IP. Patch 1 introduces a quirk with device disconnection management necessary Synopsys Designware USB3 IP with versions 3.00a and hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub. Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci platform data. Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3 IP core driver. Patch 4 introduces using a quirk based on a errata of Synopsis DesignWare USB3 IP which is versions 3.00a and has hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a result this quirk has to be enabled via platform data or device tree. Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Mathias, let me know how you want to handle this. Either I take them all, or you take them all. What do you prefer ? Mathias ? Mathias, a reminder on this series. Would any problem is still in my patchset? e.g. I might still not arrange these patch in a appropriate order so that Mathias cannot review and accept these? BR, Sneeker, sincerely -- balbi -- 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
[RFC PATCH 3/3] drm: bridge/dw_hdmi: improve hdmi single-end test
Because of iMX6 Rockchip have differnet mpll config parameter,
than the cklvl txlvl would be different, we also should seperate
this parmeter.
As for Rockchip HDMI, when pixle clock less than 148MHz, the cklvl
txlvl should be set to 13. When pixel clock less than 74.25MHz the
cklvl txlvl should be set to 17.
Signed-off-by: Yakir Yang y...@rock-chips.com
---
drivers/gpu/drm/bridge/dw_hdmi.c| 14 +++---
drivers/gpu/drm/imx/dw_hdmi-imx.c | 12 ++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
include/drm/bridge/dw_hdmi.h|5 +++--
4 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 8b3208c..869262d 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -764,7 +764,7 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
const struct dw_hdmi_plat_data *plat_data = hdmi-plat_data;
const struct dw_hdmi_mpll_config *mpll_config = plat_data-mpll_cfg;
const struct dw_hdmi_curr_ctrl *curr_ctrl = plat_data-cur_ctr;
- const struct dw_hdmi_sym_term *sym_term = plat_data-sym_term;
+ const struct dw_hdmi_phy_config *phy_config = plat_data-phy_config;
if (prep)
return -EINVAL;
@@ -835,18 +835,18 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
unsigned char prep,
hdmi_phy_i2c_write(hdmi, 0x, 0x13); /* PLLPHBYCTRL */
hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
- for (i = 0; sym_term[i].mpixelclock != (~0UL); i++)
+ for (i = 0; phy_config[i].mpixelclock != (~0UL); i++)
if (hdmi-hdmi_data.video_mode.mpixelclock =
- sym_term[i].mpixelclock)
+ phy_config[i].mpixelclock)
break;
/* RESISTANCE TERM 133Ohm Cfg */
- hdmi_phy_i2c_write(hdmi, sym_term[i].term, 0x19); /* TXTERM */
+ hdmi_phy_i2c_write(hdmi, phy_config[i].term, 0x19); /* TXTERM */
/* PREEMP Cgf 0.00 */
- hdmi_phy_i2c_write(hdmi, sym_term[i].sym_ctr, 0x09); /* CKSYMTXCTRL */
-
+ hdmi_phy_i2c_write(hdmi, phy_config[i].sym_ctr, 0x09); /* CKSYMTXCTRL */
/* TX/CK LVL 10 */
- hdmi_phy_i2c_write(hdmi, 0x01ad, 0x0E); /* VLEVCTRL */
+ hdmi_phy_i2c_write(hdmi, phy_config[i].vlev_ctr, 0x0E); /* VLEVCTRL */
+
/* REMOVE CLK TERM */
hdmi_phy_i2c_write(hdmi, 0x8000, 0x05); /* CKCALCTRL */
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 121d30c..d6095d2 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -73,10 +73,10 @@ static const struct dw_hdmi_curr_ctrl imx_cur_ctr[] = {
}
};
-static const struct dw_hdmi_sym_term imx_sym_term[] = {
- /*pixelclk symbol term*/
- { 14850, 0x800d, 0x0005 },
- { ~0UL, 0x, 0x }
+static const struct dw_hdmi_phy_config imx_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 14850, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
};
static int dw_hdmi_imx_parse_dt(struct imx_hdmi *hdmi)
@@ -139,14 +139,14 @@ static struct drm_encoder_funcs dw_hdmi_imx_encoder_funcs
= {
static struct dw_hdmi_plat_data imx6q_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr = imx_cur_ctr,
- .sym_term = imx_sym_term,
+ .phy_config = imx_phy_config,
.dev_type = IMX6Q_HDMI,
};
static struct dw_hdmi_plat_data imx6dl_hdmi_drv_data = {
.mpll_cfg = imx_mpll_cfg,
.cur_ctr = imx_cur_ctr,
- .sym_term = imx_sym_term,
+ .phy_config = imx_phy_config,
.dev_type = IMX6DL_HDMI,
};
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 51030ca..65152a9 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -139,12 +139,12 @@ static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[]
= {
}
};
-static const struct dw_hdmi_sym_term rockchip_sym_term[] = {
- /*pixelclk symbol term*/
- { 7425, 0x8009, 0x0004 },
- { 14850, 0x803b, 0x0004 },
- { 29700, 0x8039, 0x0005 },
- { ~0UL, 0x, 0x }
+static const struct dw_hdmi_phy_config rockchip_phy_config[] = {
+ /*pixelclk symbol term vlev*/
+ { 7425, 0x8009, 0x0004, 0x0251},
+ { 14850, 0x803b, 0x0004, 0x01ad},
+ { 29700, 0x8039, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
};
static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
@@ -236,7 +236,7 @@ static const struct dw_hdmi_plat_data
rockchip_hdmi_drv_data = {
.mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr= rockchip_cur_ctr,
- .sym_term
Re: [PATCH v2 1/2] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
Hi Addy,
On Mon, Feb 9, 2015 at 12:55 PM, Addy Ke addy...@rock-chips.com wrote:
Because of some uncertain factors, such as worse card or worse hardware,
DAT[3:0](the data lines) may be pulled down by card, and mmc controller
will be in busy state. This should not happend when mmc controller
send command to update card clocks. If this happends, mci_send_cmd will
be failed and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..b0b57e3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -100,6 +100,7 @@ struct idmac_desc {
};
#endif /* CONFIG_MMC_DW_IDMAC */
+static int dw_mci_card_busy(struct mmc_host *mmc);
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -888,6 +889,31 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
cmd, u32 arg)
cmd, arg, cmd_status);
}
+static void dw_mci_wait_busy(struct dw_mci_slot *slot)
+{
+ struct dw_mci *host = slot-host;
+ unsigned long timeout = jiffies + msecs_to_jiffies(500);
+
Why 500 msec?
+ do {
+ if (!dw_mci_card_busy(slot-mmc))
+ return;
+ cpu_relax();
+ } while (time_before(jiffies, timeout));
+
+ dev_err(host-dev, Data busy (status %#x)\n,
+ mci_readl(slot-host, STATUS));
+
+ /*
+* Data busy, this should not happend when mmc controller send command
+* to update card clocks in non-volt-switch state. If it happends, we
+* should reset controller to avoid getting Timeout sending command.
+*/
+ dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
+
Why you need to reset all blocks? may be CTRL_RESET is good enough here.
+ /* Fail to reset controller or still data busy, WARN_ON! */
+ WARN_ON(dw_mci_card_busy(slot-mmc));
+}
+
static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
{
struct dw_mci *host = slot-host;
@@ -899,6 +925,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot,
bool force_clkinit)
/* We must continue to set bit 28 in CMD until the change is complete
*/
if (host-state == STATE_WAITING_CMD11_DONE)
sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
+ else
+ dw_mci_wait_busy(slot);
hmm...I would suggest you to call dw_mci_wait_busy() from inside
mci_send_cmd(), seems like dw_mmc hangs while sending update clock cmd
in multiple cases.see [1]
[1]: http://permalink.gmane.org/gmane.linux.kernel.mmc/31140
if (!clock) {
mci_writel(host, CLKENA, 0);
--
1.8.3.2
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Regards,
Alim
--
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/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC
Are we certain of the split between components the PSCI implementation
must touch and those the kernel must touch?
Also add dts file to support HiKey development board which
based on Hi6220 SoC and document the devicetree bindings.
These dts files will be changed later and more nodes will be
added to describe other devices.
How is this going to be changed other than the addition of nodes?
Will this DTB continue to work in future? Or do you intend to make
changes that will break support?
My original idea is: use spin-table for SMP now, when firmware is OK to
support PSCI, we submit another patch to replace the spin-table with
PSCI.
For any users who have not updated their FW, this will break booting.
This is why I suggest having hte bootloader/FW fill this in as it should
know what enable-method the FW supports.
If DTB should continue to work in the future, we really need to remove
the spin-table
from current dts file, how about just enable one core now?
Which one do you favor or any other suggestion?
If spin-table is just for testing while you await PSCI, drop spin-table
from the dts for now.
So, just booting one core may be the right choice now, right?
Without an enable-method for secondary CPUs, that will be all that's
possible. If your FW/bootlaoder injects the appropriate enable-method,
then you could gain spin-table based SMP bringup while awaiting PSCI,
without there being a DTB compatibility issue.
For DTB compatibility issue, how about just describe one core in dts
file? when PSCI
is OK, we can add the CPU topology to the dts file again.
Given that we won't boot secondary CPUs without an enable-method, we
could leave them in, but in a currently-unusable state. That would allow
a bootloader to patch in the relevant properties to boot them.
If you add the nodes later with PSCI properties, users with existing
firmware will expect their board to boot. So I'd recommendd that the
bootloader patches that in, or that the firmware is ready prior to this
being merged. I suspect that the former is more likely to be possible.
[...]
+ pm_ctrl: pm_ctrl {
+ compatible = hisilicon,pmctrl, syscon;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x0 0xf7032000 0x0 0x1000;
+ ranges = 0 0x0 0xf7032000 0x1000;
+
+ clock_power: clock3@0 {
+ compatible =
hisilicon,hi6220-clock-power;
+ reg = 0 0x1000;
+ #clock-cells = 1;
+ };
+ };
I really doesn't see the point in having a sub-device that covers the
entirely of the register space of the containing node, and that being
the case I am extremely concerned that the containers are marked as
syscon compatible.
The SoC clocks are designed and placed under different system
controllers,
so I define corresponding nodes under different controllers for clock
operation.
What I'm concerned wit hhere is that the pm_ctrl node and the clock3@0
sub-node have the _exact_ same register space.
Given this should mean that the clock3@0 node owns that register space,
having the container node export this as syscon does not make sense. And
the split between pm_ctrl and clock3@) doesn't seem to make sense given
they cover the same space.
I understand your worry and will find the max offset of those clocks
under this controller.
As I asked before, why is pm_ctrl marked as a syscon, and what's the
point of the separate sub-node?
There is no big difference between pm_ctrl and other controller, they
are all designed as
the base address to control some functions of other modules (certainly
include some clock gates).
Are they just different instances of the same IP block, or are there
fundamental differences between them?
You can understand it as a different instance of the same IP block,
there is no fundamental
differences between them.
Ok. If that's the case each should have the same compatible string.
Thanks,
Mark.
--
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
[RFC PATCH 0/1] Improve eye-diagram single-ended test for rk3288 hdmi
RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz, and single-ended test would failed when display mode is 74.25MHz. - Fix some code style, leave space for next patches. - For hdmi eye-diagram test, we turn on the Transmitter Trailer-B and improve slopeboost to 25%-30% decrease. - For hdmi single-ended test, we set CKLVL TXLVL to 17 when pixel clock is 74.25MHz, keep CKLVL TXLVL to 13 when pixel clock is 148.5MHz. Yakir Yang (1): drm: bridge/dw_hdmi: fixed codec style drivers/gpu/drm/bridge/dw_hdmi.c |8 1 file changed, 4 insertions(+), 4 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 v3 4/5] usb: phy: load usb phy earlier
On 02/10/2015 10:49 PM, Felipe Balbi wrote: On Tue, Feb 10, 2015 at 03:04:28PM +0800, Peter Chen wrote: This patch does not belong to phy, so, doesn't need to add phy in subject, meanwhile, please add GregKH as TO list, he is the right one to queue this patch. Reply-To: In-Reply-To: 1423554627-694-5-git-send-email-zhangfei@linaro.org On Tue, Feb 10, 2015 at 03:50:26PM +0800, Zhangfei Gao wrote: Since phy is definitely used in usb controller, load the phy earlier to make boot time shorter. Signed-off-by: Zhangfei Gao zhangfei@linaro.org Acked-by: Peter Chen peter.c...@freescale.com NAK, make sure there are no such dependencies with your controller driver. They should know how to defer probing if their resources aren't available yet. Sorry for the confusion, There is no dependencies at all, just for optimization. Peter already told me this patch should not be put here, causing confusion. And I resend in another thread. The controller is dwc2, which use defer probe. And dwc2 controller defer probe every time even the phy driver in the same folder. Since we know the calling sequence, we can simply change the sequence to load the phy earlier. However, as you said the new driver will be put in drivers/phy, there should be no such issue in the future. It is OK not using this patch. Thanks -- 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 2/5] irqchip: add virtual demultiplexer implementation
Hello Peter, On Tue, 10 Feb 2015 16:00:13 +0100 Peter Zijlstra pet...@infradead.org wrote: On Thu, Jan 29, 2015 at 11:33:37AM +0100, Boris Brezillon wrote: +#ifdef CONFIG_VIRT_IRQ_DEMUX_CHIP +/** + * struct irq_chip_virt_demux - Dumb demultiplexer irq chip data structure s/Dumb/Virtual/ ? + * @domain:irq domain pointer + * @available: Bitfield of valid irqs + * @unmasked: Bitfield containing irqs status + * @flags: irq_virt_demux_flags flags + * @src_irq: irq feeding the virt demux chip + * + * Note, that irq_chip_generic can have multiple irq_chip_type + * implementations which can be associated to a particular irq line of + * an irq_chip_generic instance. That allows to share and protect + * state in an irq_chip_generic instance when we need to implement + * different flow mechanisms (level/edge) for it. This seems like a copy/paste from struct irq_chip_generic; it seems not relevant, seeing how irq_chip_virt_demux does not even have an irq_chip_type pointer list. Also, with a demuxer like this, we're bound to whatever flow type its host is, no? Absolutely, I'll fix the comment by removing those lines. +# Dumb interrupt demuxer chip implementation s/Dumb/Virtual/ ? Yep, I'll fix that one too. +#ifdef CONFIG_VIRT_IRQ_DEMUX_CHIP +/** + * handle_virt_demux_irq - Dumb demuxer irq handle function. idem + * @irq: the interrupt number + * @desc: the interrupt description structure for this irq + * + * Dumb demux interrupts are sent from a demultiplexing interrupt handler idem + * which is not able to decide which child interrupt handler should be + * called. + * + * Note: The caller is expected to handle the ack, clear, mask and + * unmask issues if necessary. + */ If we're calling multiple handlers, how can they all do this and not collide? It's the same problem as you noted above: a copy/paste that should have been reworded. I'll remove those lines too. Over all it looks good -- in as far as my (admittedly stale IRQ braincells) go. I'll go queue up these bits, if you could send me a delta patch addressing these 'minor' comment issues? Thanks, I'll send you a patch addressing your comments (it would be great if you could squash it with this patch). Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Hi Boris, On Thu, Jan 29, 2015 at 10:33:38AM +, Boris Brezillon wrote: Add documentation for the virtual irq demuxer. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- .../bindings/interrupt-controller/dumb-demux.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt diff --git a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt new file mode 100644 index 000..b9a7830 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt @@ -0,0 +1,41 @@ +* Virtual Interrupt Demultiplexer + +This virtual demultiplexer simply forward all incoming interrupts to its +enabled/unmasked children. +It is only intended to be used by hardware that do not provide a proper way +to demultiplex a source interrupt, and thus have to wake all their children +up so that they can possibly handle the interrupt (if needed). +This can be seen as an alternative to shared interrupts when at least one +of the interrupt children is a timer (and require the irq to stay enabled +on suspend) while others are not. This will prevent calling irq handlers of +non timer devices while they are suspended. This sounds like a DT-workaround for a Linux implementation problem, and I don't think this the right way to solve your problem. Why does this have to be in DT at all? Why can we not fix the core to handle these details? I am very much not keen on this binding. + +Required properties: +- compatible: Should be virtual,irq-demux. +- interrupt-controller: Identifies the node as an interrupt controller. +- interrupts-extended or interrupt-parent and interrupts: Reference the source + interrupt connected to this dumb demuxer. +- #interrupt-cells: The number of cells to define the interrupts (should be 1). + The only cell is the IRQ number. +- irqs: u32 bitfield specifying the interrupts provided by the demuxer. Arbitrary limitation? Thanks, Mark. -- 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] genirq: fix virtual irq demuxer related comments
Replace remaining 'Dumb' occurrences by 'Virtual'.
Remove inappropriate notes in kerneldoc headers.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
include/linux/irq.h | 8 +---
kernel/irq/Kconfig | 2 +-
kernel/irq/chip.c| 7 ++-
kernel/irq/virt-demux-chip.c | 2 +-
4 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index b703093..192dd85 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -886,18 +886,12 @@ static inline u32 irq_reg_readl(struct irq_chip_generic
*gc,
#ifdef CONFIG_VIRT_IRQ_DEMUX_CHIP
/**
- * struct irq_chip_virt_demux - Dumb demultiplexer irq chip data structure
+ * struct irq_chip_virt_demux - Virtual demultiplexer irq chip data structure
* @domain:irq domain pointer
* @available: Bitfield of valid irqs
* @unmasked: Bitfield containing irqs status
* @flags: irq_virt_demux_flags flags
* @src_irq: irq feeding the virt demux chip
- *
- * Note, that irq_chip_generic can have multiple irq_chip_type
- * implementations which can be associated to a particular irq line of
- * an irq_chip_generic instance. That allows to share and protect
- * state in an irq_chip_generic instance when we need to implement
- * different flow mechanisms (level/edge) for it.
*/
struct irq_chip_virt_demux {
struct irq_domain *domain;
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 506644f..f608fbe 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -51,7 +51,7 @@ config GENERIC_IRQ_CHIP
bool
select IRQ_DOMAIN
-# Dumb interrupt demuxer chip implementation
+# Virtual interrupt demuxer chip implementation
config VIRT_IRQ_DEMUX_CHIP
bool
select IRQ_DOMAIN
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 38abf8d..235595f 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -407,16 +407,13 @@ EXPORT_SYMBOL_GPL(handle_simple_irq);
#ifdef CONFIG_VIRT_IRQ_DEMUX_CHIP
/**
- * handle_virt_demux_irq - Dumb demuxer irq handle function.
+ * handle_virt_demux_irq - Virtual demuxer irq handle function.
* @irq: the interrupt number
* @desc: the interrupt description structure for this irq
*
- * Dumb demux interrupts are sent from a demultiplexing interrupt handler
+ * Virtual demux interrupts are sent from a demultiplexing interrupt
handler
* which is not able to decide which child interrupt handler should be
* called.
- *
- * Note: The caller is expected to handle the ack, clear, mask and
- * unmask issues if necessary.
*/
irqreturn_t
handle_virt_demux_irq(unsigned int irq, struct irq_desc *desc)
diff --git a/kernel/irq/virt-demux-chip.c b/kernel/irq/virt-demux-chip.c
index 31f35f0..b705d54 100644
--- a/kernel/irq/virt-demux-chip.c
+++ b/kernel/irq/virt-demux-chip.c
@@ -83,7 +83,7 @@ struct irq_domain_ops irq_virt_demux_domain_ops = {
EXPORT_SYMBOL_GPL(irq_virt_demux_domain_ops);
/**
- * irq_virt_demux_handler - Dumb demux flow handler
+ * irq_virt_demux_handler - Virtual demux flow handler
* @irq: Virtual irq number
* @irq_desc: irq descriptor
*/
--
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 v4 2/5] irqchip: add virtual demultiplexer implementation
[...]
+static int __init virt_irq_demux_of_init(struct device_node *node,
+struct device_node *parent)
+{
+ struct irq_chip_virt_demux *demux;
+ unsigned int irq;
+ u32 valid_irqs;
+ int ret;
+
+ irq = irq_of_parse_and_map(node, 0);
+ if (!irq) {
+ pr_err(Failed to retrieve virt irq demuxer source\n);
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(node, irqs, valid_irqs);
+ if (ret) {
+ pr_err(Invalid of missing 'irqs' property\n);
+ return ret;
+ }
+
+ demux = irq_alloc_virt_demux_chip(irq, valid_irqs,
+ IRQ_NOREQUEST | IRQ_NOPROBE |
+ IRQ_NOAUTOEN, 0);
+ if (!demux) {
+ pr_err(Failed to allocate virt irq demuxer struct\n);
+ return -ENOMEM;
+ }
+
+ demux-domain = irq_domain_add_linear(node, BITS_PER_LONG,
+ irq_virt_demux_domain_ops,
+ demux);
+ if (!demux-domain) {
+ ret = -ENOMEM;
+ goto err_free_demux;
+ }
+
+ ret = irq_set_handler_data(irq, demux);
+ if (ret) {
+ pr_err(Failed to assign handler data\n);
+ goto err_free_domain;
+ }
+
+ irq_set_chained_handler_nostartup(irq, irq_virt_demux_handler);
+
+ return 0;
+
+err_free_domain:
+ irq_domain_remove(demux-domain);
+
+err_free_demux:
+ kfree(demux);
+
+ return ret;
+}
+IRQCHIP_DECLARE(virt_irq_demux, virtual,irq-demux, virt_irq_demux_of_init);
As mentioned on the DT binding patch, I really don't think this should
be in the DT. It corresponds only to Linux internal details, not a piece
of hardware. If we need this internally, I don't see why it can't be
instanciated as required.
If we _must_ have this in the DT, I have concerns with the binding
w.r.t. the irqs property being a 32-bit bitmask (as opposed to say
being something like num-irqs which could be far larger, and is
easuier to read).
Thanks,
Mark.
--
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: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb
On 02/10/2015 10:48 PM, Felipe Balbi wrote: On Tue, Feb 10, 2015 at 05:10:04PM +0800, Zhangfei Gao wrote: Add usb phy controller for hi6220 platform Signed-off-by: Zhangfei Gao zhangfei@linaro.org --- drivers/usb/phy/Kconfig | 9 ++ drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-hi6220-usb.c | 306 +++ 3 files changed, 316 insertions(+) create mode 100644 drivers/usb/phy/phy-hi6220-usb.c diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index c6d0c8e..405a3d0 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -173,6 +173,15 @@ config USB_MXS_PHY MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x. +config USB_HI6220_PHY + tristate hi6220 USB PHY support + select USB_PHY + select MFD_SYSCON + help + Enable this to support the HISILICON HI6220 USB PHY. + + To compile this driver as a module, choose M here. + config USB_RCAR_PHY tristate Renesas R-Car USB PHY support depends on USB || USB_GADGET diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index 75f2bba..00172d3 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o obj-$(CONFIG_TWL6030_USB) += phy-twl6030-usb.o obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o obj-$(CONFIG_USB_GPIO_VBUS) += phy-gpio-vbus-usb.o +obj-$(CONFIG_USB_HI6220_PHY) += phy-hi6220-usb.o new drivers only on drivers/phy/, sorry. OK, thanks for the info, I don't know this at all. So even usb phy should be put under drivers/phy/. Will change that. Thanks Felipe -- 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/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC
Hello Mark,
2015-02-10 21:37 GMT+08:00 Mark Rutland mark.rutl...@arm.com:
On Fri, Feb 06, 2015 at 03:37:52PM +, Brent Wang wrote:
Hello Mark,
2015-02-06 18:44 GMT+08:00 Mark Rutland mark.rutl...@arm.com:
On Fri, Feb 06, 2015 at 08:42:22AM +, Brent Wang wrote:
Hello Mark,
2015-02-06 3:30 GMT+08:00 Mark Rutland mark.rutl...@arm.com:
On Thu, Feb 05, 2015 at 09:24:37AM +, Bintian Wang wrote:
Add initial dtsi file to support Hisilicon Hi6220 SoC with
support of Octal core CPUs in two clusters and each cluster
has quard Cortex-A53.
We now use the spin-table method for SMP, and it will be
changed to PSCI later.
If that's the case, please don't place the enable-method and related
properties in this file. Get your bootloader to add the appropriate
properties for its boot protocol.
When is PSCI likely to appear?
PSCI is under development.
Sure. Do you have an estimate as to when it will appear?
Another team will do the job, I can not give my estimation now.
Ok.
What are you using for your PSCI implementation? The ARM Trusted
Firmware?
Yes, ATF.
How are you testing it?
I think cpu hotplug can test it.
Are we certain of the split between components the PSCI implementation
must touch and those the kernel must touch?
Also add dts file to support HiKey development board which
based on Hi6220 SoC and document the devicetree bindings.
These dts files will be changed later and more nodes will be
added to describe other devices.
How is this going to be changed other than the addition of nodes?
Will this DTB continue to work in future? Or do you intend to make
changes that will break support?
My original idea is: use spin-table for SMP now, when firmware is OK to
support PSCI, we submit another patch to replace the spin-table with PSCI.
For any users who have not updated their FW, this will break booting.
This is why I suggest having hte bootloader/FW fill this in as it should
know what enable-method the FW supports.
If DTB should continue to work in the future, we really need to remove
the spin-table
from current dts file, how about just enable one core now?
Which one do you favor or any other suggestion?
If spin-table is just for testing while you await PSCI, drop spin-table
from the dts for now.
So, just booting one core may be the right choice now, right?
Without an enable-method for secondary CPUs, that will be all that's
possible. If your FW/bootlaoder injects the appropriate enable-method,
then you could gain spin-table based SMP bringup while awaiting PSCI,
without there being a DTB compatibility issue.
For DTB compatibility issue, how about just describe one core in dts
file? when PSCI
is OK, we can add the CPU topology to the dts file again.
[...]
+ pm_ctrl: pm_ctrl {
+ compatible = hisilicon,pmctrl, syscon;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x0 0xf7032000 0x0 0x1000;
+ ranges = 0 0x0 0xf7032000 0x1000;
+
+ clock_power: clock3@0 {
+ compatible =
hisilicon,hi6220-clock-power;
+ reg = 0 0x1000;
+ #clock-cells = 1;
+ };
+ };
I really doesn't see the point in having a sub-device that covers the
entirely of the register space of the containing node, and that being
the case I am extremely concerned that the containers are marked as
syscon compatible.
The SoC clocks are designed and placed under different system controllers,
so I define corresponding nodes under different controllers for clock
operation.
What I'm concerned wit hhere is that the pm_ctrl node and the clock3@0
sub-node have the _exact_ same register space.
Given this should mean that the clock3@0 node owns that register space,
having the container node export this as syscon does not make sense. And
the split between pm_ctrl and clock3@) doesn't seem to make sense given
they cover the same space.
I understand your worry and will find the max offset of those clocks
under this controller.
As I asked before, why is pm_ctrl marked as a syscon, and what's the
point of the separate sub-node?
There is no big difference between pm_ctrl and other controller, they
are all designed as
the base address to control some functions of other modules (certainly
include some clock gates).
Are they just different instances of the same IP block, or are there
fundamental differences between them?
You can understand it as a different instance of the same IP block,
there is no fundamental
differences between them.
Maybe only one node is enough, not one node plus one sub-node ?
At least in the case above, I cannot see a reason to have more than a
single node
Re: [PATCH] genirq: fix virtual irq demuxer related comments
On Tue, Feb 10, 2015 at 04:43:12PM +0100, Boris Brezillon wrote: Replace remaining 'Dumb' occurrences by 'Virtual'. Remove inappropriate notes in kerneldoc headers. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Thanks, squished into the other one. -- 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/5] usb: phy: load usb phy earlier
On Tue, Feb 10, 2015 at 03:04:28PM +0800, Peter Chen wrote: This patch does not belong to phy, so, doesn't need to add phy in subject, meanwhile, please add GregKH as TO list, he is the right one to queue this patch. Reply-To: In-Reply-To: 1423554627-694-5-git-send-email-zhangfei@linaro.org On Tue, Feb 10, 2015 at 03:50:26PM +0800, Zhangfei Gao wrote: Since phy is definitely used in usb controller, load the phy earlier to make boot time shorter. Signed-off-by: Zhangfei Gao zhangfei@linaro.org Acked-by: Peter Chen peter.c...@freescale.com NAK, make sure there are no such dependencies with your controller driver. They should know how to defer probing if their resources aren't available yet. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
I'm fixing my own answer :-) On Tue, 10 Feb 2015 16:52:01 +0100 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Mark, On Tue, 10 Feb 2015 15:36:28 + Mark Rutland mark.rutl...@arm.com wrote: Hi Boris, On Thu, Jan 29, 2015 at 10:33:38AM +, Boris Brezillon wrote: Add documentation for the virtual irq demuxer. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- .../bindings/interrupt-controller/dumb-demux.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt diff --git a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt new file mode 100644 index 000..b9a7830 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt @@ -0,0 +1,41 @@ +* Virtual Interrupt Demultiplexer + +This virtual demultiplexer simply forward all incoming interrupts to its +enabled/unmasked children. +It is only intended to be used by hardware that do not provide a proper way +to demultiplex a source interrupt, and thus have to wake all their children +up so that they can possibly handle the interrupt (if needed). +This can be seen as an alternative to shared interrupts when at least one +of the interrupt children is a timer (and require the irq to stay enabled +on suspend) while others are not. This will prevent calling irq handlers of +non timer devices while they are suspended. This sounds like a DT-workaround for a Linux implementation problem, and I don't think this the right way to solve your problem. I understand your concern, but why are you answering while I asked for but why are you answering now, while DT maintainers reviews for several days (if not several weeks). Why does this have to be in DT at all? Why can we not fix the core to handle these details? We already discussed that with Rob and Thomas, and hiding such a demuxer chip is not an easy task. I'm open to any suggestion to do that, though I'd like you (I mean DT guys) to provide a working implementation (or at least a viable concept) that would silently demultiplex an irq. I am very much not keen on this binding. Yes, but do you have anything else to propose. We're experiencing this warning for 2 releases now, and this is time to find a solution (even if it's not a perfect one). + +Required properties: +- compatible: Should be virtual,irq-demux. +- interrupt-controller: Identifies the node as an interrupt controller. +- interrupts-extended or interrupt-parent and interrupts: Reference the source + interrupt connected to this dumb demuxer. +- #interrupt-cells: The number of cells to define the interrupts (should be 1). + The only cell is the IRQ number. +- irqs: u32 bitfield specifying the interrupts provided by the demuxer. Arbitrary limitation? I first proposed to make this field unlimited, but Thomas suggested to keep it limited to 32 bits (and I didn't complain since my HW needs far less than 32 interrupts). Here is the first implementation I proposed [1], where the 'irqs' property was an array of u32, each entry containing an irq id. [1]https://lkml.org/lkml/2015/1/8/233 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb
Signed-off-by: Zhangfei Gao zhangfei@linaro.org --- drivers/usb/phy/Kconfig | 9 ++ drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-hi6220-usb.c | 306 +++ 3 files changed, 316 insertions(+) create mode 100644 drivers/usb/phy/phy-hi6220-usb.c diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index c6d0c8e..405a3d0 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -173,6 +173,15 @@ config USB_MXS_PHY MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x. +config USB_HI6220_PHY + tristate hi6220 USB PHY support + select USB_PHY + select MFD_SYSCON + help + Enable this to support the HISILICON HI6220 USB PHY. + + To compile this driver as a module, choose M here. + config USB_RCAR_PHY tristate Renesas R-Car USB PHY support depends on USB || USB_GADGET diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile index 75f2bba..00172d3 100644 --- a/drivers/usb/phy/Makefile +++ b/drivers/usb/phy/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_SAMSUNG_USBPHY) += phy- samsung-usb.o obj-$(CONFIG_TWL6030_USB) += phy-twl6030-usb.o obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o +obj-$(CONFIG_USB_HI6220_PHY) += phy-hi6220-usb.o new drivers only on drivers/phy/, sorry. This driver has many USB dependencies, like otg, gadget. I don't know it can use generic phy currently. Peter -- 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/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC
Hello Mark,
2015-02-10 23:27 GMT+08:00 Mark Rutland mark.rutl...@arm.com:
[...]
+ pm_ctrl: pm_ctrl {
+ compatible = hisilicon,pmctrl, syscon;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x0 0xf7032000 0x0 0x1000;
+ ranges = 0 0x0 0xf7032000 0x1000;
+
+ clock_power: clock3@0 {
+ compatible =
hisilicon,hi6220-clock-power;
+ reg = 0 0x1000;
+ #clock-cells = 1;
+ };
+ };
I really doesn't see the point in having a sub-device that covers the
entirely of the register space of the containing node, and that being
the case I am extremely concerned that the containers are marked as
syscon compatible.
The SoC clocks are designed and placed under different system
controllers,
so I define corresponding nodes under different controllers for clock
operation.
What I'm concerned wit hhere is that the pm_ctrl node and the clock3@0
sub-node have the _exact_ same register space.
Given this should mean that the clock3@0 node owns that register space,
having the container node export this as syscon does not make sense. And
the split between pm_ctrl and clock3@) doesn't seem to make sense given
they cover the same space.
I understand your worry and will find the max offset of those clocks
under this controller.
As I asked before, why is pm_ctrl marked as a syscon, and what's the
point of the separate sub-node?
There is no big difference between pm_ctrl and other controller, they
are all designed as
the base address to control some functions of other modules (certainly
include some clock gates).
Are they just different instances of the same IP block, or are there
fundamental differences between them?
You can understand it as a different instance of the same IP block,
there is no fundamental
differences between them.
Ok. If that's the case each should have the same compatible string.
Although they have same function, they control different domain, I
should use different compatible string to distinguish different
domains.
Thanks,
Bintian
Thanks,
Mark.
--
Best Regards,
Bintian
===
Don't be nervous, just be happy!
--
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 00/10] ASoC: QCOM: Add support for ipq806x SOC
On Sun, Feb 08, 2015 at 10:45:11PM -0800, Kenneth Westfield wrote: On Sat, Feb 07, 2015 at 06:32:29AM +0800, Mark Brown wrote: I'd really like to see some discussion as to how this is all supposed to be handled - how will these direct hardware access drivers and device trees work when someone does want to use the DSP (without causing problems), and how will we transition from one to the other. This is particularly pressing if there are use cases where people will want to switch between the two modes at runtime. What I'm trying to avoid here is being in a situation where we have existing stable DT bindings which we have to support but which conflict with the way that people want to use the systems. The ipq806x SOC has no LPASS DSP. On SOCs with a DSP, these drivers would not be enabled. OK, but I'm guessing that they're using the same IP that is in other SoCs which do have the DSP so even if you don't care for this device it might still be an issue. These drivers are prefixed with lpass to differentiate themselves from other drivers that would interact with a DSP, rather than the LPASS hardware directly. Right, it may be that all that's needed here is some indication as to how to describe a system which *does* have a DSP. Perhaps require that the devices be children of the DSP, that way if people want to access the hardware directly they can load a dummy driver for the DSP that just passes things through if they don't want to use the DSP? signature.asc Description: Digital signature
Re: [PATCH 2/2] ARM: perf: Add support for Scorpion PMUs
Hi Stephen,
On 10 February 2015 at 20:05, Stephen Boyd sb...@codeaurora.org wrote:
Scorpion supports a set of local performance monitor event
selection registers (LPM) sitting behind a cp15 based interface
that extend the architected PMU events to include Scorpion CPU
and Venum VFP specific events. To use these events the user is
expected to program the lpm register with the event code shifted
into the group they care about and then point the PMNx event at
that region+group combo by writing a LPMn_GROUPx event. Add
support for this hardware.
Note: the raw event number is a pure software construct that
allows us to map the multi-dimensional number space of regions,
groups, and event codes into a flat event number space suitable
for use by the perf framework.
This is based on code originally written by Ashwin Chaugule and
Neil Leeder [1] massed to become similar to the Krait PMU support
code.
Thanks for taking this up!
Overall this series looks good to me, but from what I faintly
recollect, doesn't this (and the Krait pmu code) get affected by
powercollapse issues anymore?
e.g.
https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/arch/arm/kernel/perf_event_msm.c?h=msm-3.4id=b5ca687960f0fea2f4735e83ca5c9543474c19de
Thanks,
Ashwin.
[1]
https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/kernel/perf_event_msm.c?h=msm-3.4
Cc: Neil Leeder nlee...@codeaurora.org
Cc: Ashwin Chaugule ashw...@codeaurora.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
Documentation/devicetree/bindings/arm/pmu.txt | 2 +
arch/arm/kernel/perf_event_cpu.c | 2 +
arch/arm/kernel/perf_event_v7.c | 395
++
3 files changed, 399 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/pmu.txt
b/Documentation/devicetree/bindings/arm/pmu.txt
index 75ef91d08f3b..6e54a9d88b7a 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -18,6 +18,8 @@ Required properties:
arm,arm11mpcore-pmu
arm,arm1176-pmu
arm,arm1136-pmu
+ qcom,scorpion-pmu
+ qcom,scorpion-mp-pmu
qcom,krait-pmu
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a
per-cpu
interrupt (PPI) then 1 interrupt should be specified.
diff --git a/arch/arm/kernel/perf_event_cpu.c
b/arch/arm/kernel/perf_event_cpu.c
index dd9acc95ebc0..010ffd241434 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -242,6 +242,8 @@ static struct of_device_id cpu_pmu_of_device_ids[] = {
{.compatible = arm,arm11mpcore-pmu, .data = armv6mpcore_pmu_init},
{.compatible = arm,arm1176-pmu, .data = armv6_1176_pmu_init},
{.compatible = arm,arm1136-pmu, .data = armv6_1136_pmu_init},
+ {.compatible = qcom,scorpion-pmu, .data = scorpion_pmu_init},
+ {.compatible = qcom,scorpion-mp-pmu, .data = scorpion_pmu_init},
{.compatible = qcom,krait-pmu,.data = krait_pmu_init},
{},
};
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 84a3ec3bc592..14bc8726f554 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -140,6 +140,23 @@ enum krait_perf_types {
KRAIT_PERFCTR_L1_DTLB_ACCESS= 0x12210,
};
+/* ARMv7 Scorpion specific event types */
+enum scorpion_perf_types {
+ SCORPION_LPM0_GROUP0= 0x4c,
+ SCORPION_LPM1_GROUP0= 0x50,
+ SCORPION_LPM2_GROUP0= 0x54,
+ SCORPION_L2LPM_GROUP0 = 0x58,
+ SCORPION_VLPM_GROUP0= 0x5c,
+
+ SCORPION_ICACHE_ACCESS = 0x10053,
+ SCORPION_ICACHE_MISS= 0x10052,
+
+ SCORPION_DTLB_ACCESS= 0x12013,
+ SCORPION_DTLB_MISS = 0x12012,
+
+ SCORPION_ITLB_MISS = 0x12021,
+};
+
/*
* Cortex-A8 HW events mapping
*
@@ -482,6 +499,51 @@ static const unsigned
krait_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
};
/*
+ * Scorpion HW events mapping
+ */
+static const unsigned scorpion_perf_map[PERF_COUNT_HW_MAX] = {
+ PERF_MAP_ALL_UNSUPPORTED,
+ [PERF_COUNT_HW_CPU_CYCLES] = ARMV7_PERFCTR_CPU_CYCLES,
+ [PERF_COUNT_HW_INSTRUCTIONS]= ARMV7_PERFCTR_INSTR_EXECUTED,
+ [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = ARMV7_PERFCTR_PC_WRITE,
+ [PERF_COUNT_HW_BRANCH_MISSES] =
ARMV7_PERFCTR_PC_BRANCH_MIS_PRED,
+ [PERF_COUNT_HW_BUS_CYCLES] = ARMV7_PERFCTR_CLOCK_CYCLES,
+};
+
+static const unsigned scorpion_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
+
RE: [PATCH v3 4/5] usb: phy: load usb phy earlier
On Tue, Feb 10, 2015 at 03:04:28PM +0800, Peter Chen wrote: This patch does not belong to phy, so, doesn't need to add phy in subject, meanwhile, please add GregKH as TO list, he is the right one to queue this patch. Reply-To: In-Reply-To: 1423554627-694-5-git-send-email-zhangfei@linaro.org On Tue, Feb 10, 2015 at 03:50:26PM +0800, Zhangfei Gao wrote: Since phy is definitely used in usb controller, load the phy earlier to make boot time shorter. Signed-off-by: Zhangfei Gao zhangfei@linaro.org Acked-by: Peter Chen peter.c...@freescale.com NAK, make sure there are no such dependencies with your controller driver. They should know how to defer probing if their resources aren't available yet. I NAKed it first. But after thinking more, I think it is a good patch, USB PHY works proper is the base for coming USB controller operation, with this patch, it can avoid the controller drivers which are linked earlier than USB PHY always being probed deferral, look at drivers/Makefile, it links drivers follow the similar method. Zhangfei, you may need to add more description in your commit log to prove it is a good improvement. Peter -- 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] mmc: dw_mmc: fix bug that cause mmc_test failture
On 2015/02月10日 17:34, Olof Johansson wrote: Hi Addy, On Mon, Jan 26, 2015 at 4:04 AM, Addy Ke addy...@rock-chips.com wrote: The STOP command can terminate a data transfer between a memory card and mmc controller. As show in Synopsys DesignWare Cores Mobile Stroage Host Databook: Data timeout and Data end-bit error will terminate further data transfer by mmc controller. So we should not send abort command to terminate a data transfer again if we got DRTO and EBE interrupt. After this patch, all mmc_test cases can pass on RK3288-Pink2 board. Signed-off-by: Addy Ke addy...@rock-chips.com The drawback of having so many people on your to: list on a patch is that it's unclear who you want to review and merge it. Sometimes less is more. I will remove some unnecessary mail address from list in the following patch. Thank you. In this case, it seems appropriate to have Ulf do so. Ulf, ping? This seems like a reasonable patch for 3.20 given that it fixes undesired behavior. -Olof -- 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/4] mmc: pwrseq: Initial support for the simple MMC power sequence provider
[...]
+int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
+{
+ struct mmc_pwrseq_simple *pwrseq;
+
+ pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
+ host-pwrseq = pwrseq-pwrseq;
How about making this function return a struct mmc_pwrseq * so this
last line can be moved to mmc_pwrseq_alloc() instead of requiring all
power sequences to do it?
The same applies to
host-pwrseq = NULL;
in mmc_pwrseq_simple_free(), which could be done in mmc_pwrseq_free() it
seems.
Thanks for reviewing!
I like you suggestion, though $subject patch is already part of the PR for 3.20.
Feel free to send a patch, I would happily apply it.
Kind regards
Uffe
--
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 4/4] mmc: pwrseq_simple: Add support for a reset GPIO pin
On 10 February 2015 at 10:12, Alexandre Courbot gnu...@gmail.com wrote:
On Mon, Jan 19, 2015 at 6:13 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
The need for reset GPIOs has several times been pointed out from
erlier posted patchsets. Especially some WLAN chips which are
attached to an SDIO interface may use a GPIO reset.
The reset GPIO is asserted at initialization and prior we start the
power up procedure. The GPIO will be de-asserted right after the power
has been provided to the card, from the -post_power_on() callback.
Note, the reset GPIO is optional. Thus we don't return an error even if
we can't find a GPIO for the consumer.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Excellent, with this I can probe the wifi chip on NVIDIA SHIELD which
requires a GPIO to be high for reset to be de-asserted.
The series:
Tested-by: Alexandre Courbot acour...@nvidia.com
Thanks for testing! Unfortunate, I can't add you tag since this
patchset is already in the PR for 3.20.
---
Changes in v4:
- Fixed call to kfree().
---
drivers/mmc/core/pwrseq_simple.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/mmc/core/pwrseq_simple.c
b/drivers/mmc/core/pwrseq_simple.c
index 61c991e..0958c69 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
#include linux/slab.h
#include linux/device.h
#include linux/err.h
+#include linux/gpio/consumer.h
#include linux/mmc/host.h
@@ -18,31 +19,68 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
};
+static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ if (!IS_ERR(pwrseq-reset_gpio))
+ gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+}
+
+static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ if (!IS_ERR(pwrseq-reset_gpio))
+ gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+}
+
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ if (!IS_ERR(pwrseq-reset_gpio))
+ gpiod_put(pwrseq-reset_gpio);
+
kfree(pwrseq);
host-pwrseq = NULL;
}
static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
+ .pre_power_on = mmc_pwrseq_simple_pre_power_on,
+ .post_power_on = mmc_pwrseq_simple_post_power_on,
+ .power_off = mmc_pwrseq_simple_pre_power_on,
.free = mmc_pwrseq_simple_free,
};
int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
{
struct mmc_pwrseq_simple *pwrseq;
+ int ret = 0;
pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;
+ pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0,
GPIOD_OUT_HIGH);
gpiod_get() will translate to exactly the same, with less characters.
Actually I see that the version in -next has support for multiple
GPIOs. You will probably want to look at Rojhalat's latest work on
GPIO arrays:
http://permalink.gmane.org/gmane.linux.kernel.gpio/6126
Cool!
This code would be a great candidate to use this GPIO array API, but
since it is not in -next yet (should happen soon though) you might
want to consider doing it later.
Btw, I wasted a considerable amount of time on one of the defunct
previous attempts at power sequences, so I'm interested in reviewing
future versions of this patchset if you don't mind adding me to the CC
list. :)
:-)
I will keep you posted for future updates. Feel free to post patches
improving the mmc-pwrseq code yourself, I will happily review them.
Kind regards
Uffe
--
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/4] mmc: pwrseq: Initial support for the simple MMC power sequence provider
On Wed, Feb 11, 2015 at 1:28 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
[...]
+int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
+{
+ struct mmc_pwrseq_simple *pwrseq;
+
+ pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
+ host-pwrseq = pwrseq-pwrseq;
How about making this function return a struct mmc_pwrseq * so this
last line can be moved to mmc_pwrseq_alloc() instead of requiring all
power sequences to do it?
The same applies to
host-pwrseq = NULL;
in mmc_pwrseq_simple_free(), which could be done in mmc_pwrseq_free() it
seems.
Thanks for reviewing!
I like you suggestion, though $subject patch is already part of the PR for
3.20.
Feel free to send a patch, I would happily apply it.
Damn, why am I always so late to review patches...
I will send a fixup patch - better to have this done early.
Thanks!
--
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 1/2] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
On 2015/02/09 18:01, Jaehoon Chung wrote:
Hi, Addy.
On 02/09/2015 04:25 PM, Addy Ke wrote:
Because of some uncertain factors, such as worse card or worse hardware,
DAT[3:0](the data lines) may be pulled down by card, and mmc controller
will be in busy state. This should not happend when mmc controller
send command to update card clocks. If this happends, mci_send_cmd will
be failed and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..b0b57e3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -100,6 +100,7 @@ struct idmac_desc {
};
#endif /* CONFIG_MMC_DW_IDMAC */
+static int dw_mci_card_busy(struct mmc_host *mmc);
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -888,6 +889,31 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg)
cmd, arg, cmd_status);
}
+static void dw_mci_wait_busy(struct dw_mci_slot *slot)
+{
+ struct dw_mci *host = slot-host;
+ unsigned long timeout = jiffies + msecs_to_jiffies(500);
+
+ do {
+ if (!dw_mci_card_busy(slot-mmc))
+ return;
+ cpu_relax();
+ } while (time_before(jiffies, timeout));
+
+ dev_err(host-dev, Data busy (status %#x)\n,
+ mci_readl(slot-host, STATUS));
+
+ /*
+* Data busy, this should not happend when mmc controller send command
+* to update card clocks in non-volt-switch state. If it happends, we
+* should reset controller to avoid getting Timeout sending command.
+*/
+ dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
If reset is failed, then dw_mci_ctrl_reset should return false.
ret = dw_mci_ctrl_reset();
WARN_ON(!ret || dw_mci_card_busy(slot-mmc));
Is it right?
you are right, and I will update it in my next version patch. thank you.
In my experiment, if reset is failed or card is busy, eMMC can't work
anymore..right?
I think this patch is reasonable to prevent blocking issue.
Best Regards,
Jaehoon Chung
+
+ /* Fail to reset controller or still data busy, WARN_ON! */
+ WARN_ON(dw_mci_card_busy(slot-mmc));
+}
+
static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
{
struct dw_mci *host = slot-host;
@@ -899,6 +925,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool
force_clkinit)
/* We must continue to set bit 28 in CMD until the change is complete */
if (host-state == STATE_WAITING_CMD11_DONE)
sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
+ else
+ dw_mci_wait_busy(slot);
if (!clock) {
mci_writel(host, CLKENA, 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
[PATCH] ARM: dts: BCM63xx: fix L2 cache properties
The L2 cache properties were completely off with respect to what the hardware is configured for. Fix the cache-size, cache-line-size and cache-sets to reflect the L2 cache controller we have: 512KB, 16 ways and 32 bytes per cache-line. Fixes: 46d4bca0445a0 (ARM: BCM63XX: add BCM63138 minimal Device Tree) Signed-off-by: Florian Fainelli f.faine...@gmail.com --- arch/arm/boot/dts/bcm63138.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/bcm63138.dtsi b/arch/arm/boot/dts/bcm63138.dtsi index d2d8e94e0aa2..f46329c8ad75 100644 --- a/arch/arm/boot/dts/bcm63138.dtsi +++ b/arch/arm/boot/dts/bcm63138.dtsi @@ -66,8 +66,9 @@ reg = 0x1d000 0x1000; cache-unified; cache-level = 2; - cache-sets = 16; - cache-size = 0x8; + cache-size = 524288; + cache-sets = 1024; + cache-line-size = 32; interrupts = GIC_PPI 0 IRQ_TYPE_LEVEL_HIGH; }; -- 2.1.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 v2 1/2] mmc: dw_mmc: fix bug that cause 'Timeout sending command'
On 2015/02/10 23:22, Alim Akhtar wrote:
Hi Addy,
On Mon, Feb 9, 2015 at 12:55 PM, Addy Ke addy...@rock-chips.com wrote:
Because of some uncertain factors, such as worse card or worse hardware,
DAT[3:0](the data lines) may be pulled down by card, and mmc controller
will be in busy state. This should not happend when mmc controller
send command to update card clocks. If this happends, mci_send_cmd will
be failed and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..b0b57e3 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -100,6 +100,7 @@ struct idmac_desc {
};
#endif /* CONFIG_MMC_DW_IDMAC */
+static int dw_mci_card_busy(struct mmc_host *mmc);
static bool dw_mci_reset(struct dw_mci *host);
static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 reset);
@@ -888,6 +889,31 @@ static void mci_send_cmd(struct dw_mci_slot *slot, u32
cmd, u32 arg)
cmd, arg, cmd_status);
}
+static void dw_mci_wait_busy(struct dw_mci_slot *slot)
+{
+ struct dw_mci *host = slot-host;
+ unsigned long timeout = jiffies + msecs_to_jiffies(500);
+
Why 500 msec?
This timeout value is the same as mci_send_cmd:
static void mci_send_cmd(struct dw_mci_slot *slot, u32 cmd, u32 arg)
{
struct dw_mci *host = slot-host;
unsigned long timeout = jiffies + msecs_to_jiffies(500);
}
I have not clear that which is suitable.
Do you have any suggestion on it?
+ do {
+ if (!dw_mci_card_busy(slot-mmc))
+ return;
+ cpu_relax();
+ } while (time_before(jiffies, timeout));
+
+ dev_err(host-dev, Data busy (status %#x)\n,
+ mci_readl(slot-host, STATUS));
+
+ /*
+* Data busy, this should not happend when mmc controller send command
+* to update card clocks in non-volt-switch state. If it happends, we
+* should reset controller to avoid getting Timeout sending command.
+*/
+ dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS);
+
Why you need to reset all blocks? may be CTRL_RESET is good enough here.
I have tested on rk3288, if only reset ctroller, data busy bit will not
be cleaned,and we will still get
Timeout sending command.
+ /* Fail to reset controller or still data busy, WARN_ON! */
+ WARN_ON(dw_mci_card_busy(slot-mmc));
+}
+
static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool force_clkinit)
{
struct dw_mci *host = slot-host;
@@ -899,6 +925,8 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot, bool
force_clkinit)
/* We must continue to set bit 28 in CMD until the change is complete
*/
if (host-state == STATE_WAITING_CMD11_DONE)
sdmmc_cmd_bits |= SDMMC_CMD_VOLT_SWITCH;
+ else
+ dw_mci_wait_busy(slot);
hmm...I would suggest you to call dw_mci_wait_busy() from inside
mci_send_cmd(), seems like dw_mmc hangs while sending update clock cmd
in multiple cases.see [1]
[1]: http://permalink.gmane.org/gmane.linux.kernel.mmc/31140
I think this patch is more reasonable.
So I will resend patches based on this patch.
thank you!
if (!clock) {
mci_writel(host, CLKENA, 0);
--
1.8.3.2
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] arm64: dts: Fix GIC reg sizes for APM X-Gene
Hi, On Tue, Jan 27, 2015 at 3:02 PM, Jon Masters j...@redhat.com wrote: On 01/27/2015 02:03 AM, Pranavkumar Sawargaonkar wrote: In APM X-Gene, GIC register space is 64K aligned while the sizes mentioned in the dt are 4K aligned. This breaks KVM when kernel is built with 64K page size due to size alignment checking in vgic driver for VCPU Control and VCPU register. This patch corrects the sizes to be inline with the hardware spec. CC: linux-arm-ker...@lists.infradead.org CC: kvm...@lists.cs.columbia.edu CC: a...@arndb.de CC: marc.zyng...@arm.com CC: christoffer.d...@linaro.org CC: j...@redhat.com Signed-off-by: Pranavkumar Sawargaonkar psawargaon...@apm.com Signed-off-by: Tushar Jagad tja...@apm.com Signed-off-by: Feng Kan f...@apm.com --- arch/arm64/boot/dts/apm/apm-storm.dtsi |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi b/arch/arm64/boot/dts/apm/apm-storm.dtsi index f1ad9c2..65f0e6d 100644 --- a/arch/arm64/boot/dts/apm/apm-storm.dtsi +++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi @@ -81,10 +81,10 @@ compatible = arm,cortex-a15-gic; #interrupt-cells = 3; interrupt-controller; - reg = 0x0 0x7801 0x0 0x1000, /* GIC Dist */ - 0x0 0x7802 0x0 0x1000, /* GIC CPU */ - 0x0 0x7804 0x0 0x2000, /* GIC VCPU Control */ - 0x0 0x7806 0x0 0x2000; /* GIC VCPU */ + reg = 0x0 0x7801 0x0 0x1, /* GIC Dist */ + 0x0 0x7802 0x0 0x2, /* GIC CPU */ + 0x0 0x7804 0x0 0x1, /* GIC VCPU Control */ + 0x0 0x7806 0x0 0x2; /* GIC VCPU */ interrupts = 1 9 0xf04; /* GIC Maintenence IRQ */ }; Any comments on this patch ? Thanks. I confirm that we have tested this. Jon. Thanks, Pranav -- 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] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Tue, 10 Feb 2015 16:16:00 + Mark Rutland mark.rutl...@arm.com wrote: On Tue, Feb 10, 2015 at 03:52:01PM +, Boris Brezillon wrote: Hi Mark, On Tue, 10 Feb 2015 15:36:28 + Mark Rutland mark.rutl...@arm.com wrote: Hi Boris, On Thu, Jan 29, 2015 at 10:33:38AM +, Boris Brezillon wrote: Add documentation for the virtual irq demuxer. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- .../bindings/interrupt-controller/dumb-demux.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt diff --git a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt new file mode 100644 index 000..b9a7830 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt @@ -0,0 +1,41 @@ +* Virtual Interrupt Demultiplexer + +This virtual demultiplexer simply forward all incoming interrupts to its +enabled/unmasked children. +It is only intended to be used by hardware that do not provide a proper way +to demultiplex a source interrupt, and thus have to wake all their children +up so that they can possibly handle the interrupt (if needed). +This can be seen as an alternative to shared interrupts when at least one +of the interrupt children is a timer (and require the irq to stay enabled +on suspend) while others are not. This will prevent calling irq handlers of +non timer devices while they are suspended. This sounds like a DT-workaround for a Linux implementation problem, and I don't think this the right way to solve your problem. I understand your concern, but why are you answering while I asked for DT maintainers reviews for several days (if not several weeks). I am sorry that I did not spot those, and I am very sorry that this means I am only now able to air my concerns. Why does this have to be in DT at all? Why can we not fix the core to handle these details? We already discussed that with Rob and Thomas, and hiding such a demuxer chip is not an easy task. I'm open to any suggestion to do that, though I'd like you (I mean DT guys) to provide a working implementation (or at least a viable concept) that would silently demultiplex an irq. Is it truly necessary to drop a emux in the middle? As far as I can see, all that we're attempting to do here is hide the IRQF_NO_SUSPEND mismatch from the core IRQ code, though I've only just started digging and haven't yet figured out where/why the core code cares. Any hints? You should have a look at this thread [1] ;-) [1]https://lkml.org/lkml/2014/12/15/552 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v3 0/6] GSBI CRCI Autoconfiguration Support
On Feb 9, 2015, at 4:01 PM, Andy Gross agr...@codeaurora.org wrote: This patch set adds support for automatic configuration of GSBI DMA CRCI values. DMA operations require that the ADM CRCI mux values be properly configured in the TCSR (Top Control and Status Register) block. During probing of a GSBI device, the client mode must be declared and this can be used to lookup the correct TCSR ADM CRCI MUX settings and then program them so that they are correct before any clients are populated. These patches add the TCSR as a syscon device and that allows the GSBI to access and manipulate the ADM CRCI MUX registers to correctly configure the values based on the GSBI port configuration. Changes since v2: - Use cell-index instead of alias to denote GSBI instance Changes since v1: - Fixed various review comments Andy Gross (6): soc: qcom: gsbi: Add support for ADM CRCI muxing mfd: qcom,tcsr: Add device tree binding for TCSR ARM: DT: apq8064: Add TCSR support ARM: DT: ipq8064: Add TCSR support ARM: DT: msm8660: Add TCSR support ARM: DT: msm8960: Add TCSR support .../devicetree/bindings/mfd/qcom,tcsr.txt | 22 +++ .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 14 +- arch/arm/boot/dts/qcom-apq8064.dtsi| 14 ++ arch/arm/boot/dts/qcom-ipq8064.dtsi| 14 ++ arch/arm/boot/dts/qcom-msm8660.dtsi|8 ++ arch/arm/boot/dts/qcom-msm8960.dtsi|8 ++ drivers/soc/qcom/Kconfig |1 + drivers/soc/qcom/qcom_gsbi.c | 152 8 files changed, 232 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mfd/qcom,tcsr.txt Series looks good, do we need a qcom_defconfig update to enable anything new for this? - k -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Tue, Feb 10, 2015 at 03:52:01PM +, Boris Brezillon wrote: Hi Mark, On Tue, 10 Feb 2015 15:36:28 + Mark Rutland mark.rutl...@arm.com wrote: Hi Boris, On Thu, Jan 29, 2015 at 10:33:38AM +, Boris Brezillon wrote: Add documentation for the virtual irq demuxer. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- .../bindings/interrupt-controller/dumb-demux.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt diff --git a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt new file mode 100644 index 000..b9a7830 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt @@ -0,0 +1,41 @@ +* Virtual Interrupt Demultiplexer + +This virtual demultiplexer simply forward all incoming interrupts to its +enabled/unmasked children. +It is only intended to be used by hardware that do not provide a proper way +to demultiplex a source interrupt, and thus have to wake all their children +up so that they can possibly handle the interrupt (if needed). +This can be seen as an alternative to shared interrupts when at least one +of the interrupt children is a timer (and require the irq to stay enabled +on suspend) while others are not. This will prevent calling irq handlers of +non timer devices while they are suspended. This sounds like a DT-workaround for a Linux implementation problem, and I don't think this the right way to solve your problem. I understand your concern, but why are you answering while I asked for DT maintainers reviews for several days (if not several weeks). I am sorry that I did not spot those, and I am very sorry that this means I am only now able to air my concerns. Why does this have to be in DT at all? Why can we not fix the core to handle these details? We already discussed that with Rob and Thomas, and hiding such a demuxer chip is not an easy task. I'm open to any suggestion to do that, though I'd like you (I mean DT guys) to provide a working implementation (or at least a viable concept) that would silently demultiplex an irq. Is it truly necessary to drop a emux in the middle? As far as I can see, all that we're attempting to do here is hide the IRQF_NO_SUSPEND mismatch from the core IRQ code, though I've only just started digging and haven't yet figured out where/why the core code cares. Any hints? I am very much not keen on this binding. Yes, but do you have anything else to propose. We're experiencing this warning for 2 releases now, and this is time to find a solution (even if it's not a perfect one). I appreciate this, and I am really sorry that I have come to this so late. +Required properties: +- compatible: Should be virtual,irq-demux. +- interrupt-controller: Identifies the node as an interrupt controller. +- interrupts-extended or interrupt-parent and interrupts: Reference the source + interrupt connected to this dumb demuxer. +- #interrupt-cells: The number of cells to define the interrupts (should be 1). + The only cell is the IRQ number. +- irqs: u32 bitfield specifying the interrupts provided by the demuxer. Arbitrary limitation? I first proposed to make this field unlimited, but Thomas suggested to keep it limited to 32 bits (and I didn't complain since my HW needs far less than 32 interrupts). Ok. Thanks, Mark. -- 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 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
On 2/10/2015 12:33 AM, Wolfram Sang wrote: Thanks, Wolfram. I think I'm missing something here and would like to get it clarified, so I don't make the same mistake again in the future: I thought I've already sent these patches as a new thread, i.e., [PATCH v9 ...], isn't it? Yes, but In-Reply-To was set and so my MUAs (mutt and Thunderbird) threaded them to your first submission. Most people I know prefer to have this not threaded. Okay I got it now. Thanks. Ray -- 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 0/2] Support disable the wakeup event of gpio-charger
If you needn't the wakeup event of gpio-charger, this patch can help. Please set gpio-charger,disable-wakeup in gpio-charger node. Chris Zhong (2): dt-bindings: add disable-wakeup property for gpio-charger power: gpio-charger: support disable the wakeup event Documentation/devicetree/bindings/power_supply/gpio-charger.txt | 2 ++ drivers/power/gpio-charger.c| 5 - include/linux/power/gpio-charger.h | 1 + 3 files changed, 7 insertions(+), 1 deletion(-) -- 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 v5 4/5] ARM: mediatek: Add EINT support to MTK pinctrl driver.
On Wed, Jan 21, 2015 at 1:28 PM, Hongzhou Yang hongzhou.y...@mediatek.com wrote: From: Maoguang Meng maoguang.m...@mediatek.com MTK SoC support external interrupt(EINT) from most SoC pins. Add EINT support to pinctrl driver. Signed-off-by: Maoguang Meng maoguang.m...@mediatek.com Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com Patch applied. Yours, Linus Walleij -- 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/4] mmc: pwrseq: Initial support for the simple MMC power sequence provider
On Mon, Jan 19, 2015 at 6:13 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
To add the core part for the MMC power sequence, let's start by adding
initial support for the simple MMC power sequence provider.
In this initial step, the MMC power sequence node are fetched and the
compatible string for the simple MMC power sequence provider are
verified.
At this point we don't parse the node for any properties, but instead
that will be handled from following patches. Since there are no
properties supported yet, let's just implement the -alloc() and the
-free() callbacks.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v4:
- Fixed call to kfree().
---
drivers/mmc/core/Makefile| 2 +-
drivers/mmc/core/pwrseq.c| 61
+++-
drivers/mmc/core/pwrseq.h| 2 ++
drivers/mmc/core/pwrseq_simple.c | 48 +++
4 files changed, 111 insertions(+), 2 deletions(-)
create mode 100644 drivers/mmc/core/pwrseq_simple.c
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index ccdd35f..b39cbd2 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -8,5 +8,5 @@ mmc_core-y := core.o bus.o host.o \
sdio.o sdio_ops.o sdio_bus.o \
sdio_cis.o sdio_io.o sdio_irq.o \
quirks.o slot-gpio.o
-mmc_core-$(CONFIG_OF) += pwrseq.o
+mmc_core-$(CONFIG_OF) += pwrseq.o pwrseq_simple.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/pwrseq.c b/drivers/mmc/core/pwrseq.c
index bd08772..2cea00e 100644
--- a/drivers/mmc/core/pwrseq.c
+++ b/drivers/mmc/core/pwrseq.c
@@ -7,14 +7,73 @@
*
* MMC power sequence management
*/
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/err.h
+#include linux/of.h
+#include linux/of_platform.h
+
#include linux/mmc/host.h
#include pwrseq.h
+struct mmc_pwrseq_match {
+ const char *compatible;
+ int (*alloc)(struct mmc_host *host, struct device *dev);
+};
+
+static struct mmc_pwrseq_match pwrseq_match[] = {
+ {
+ .compatible = mmc-pwrseq-simple,
+ .alloc = mmc_pwrseq_simple_alloc,
+ },
+};
+
+static struct mmc_pwrseq_match *mmc_pwrseq_find(struct device_node *np)
+{
+ struct mmc_pwrseq_match *match = ERR_PTR(-ENODEV);
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(pwrseq_match); i++) {
+ if (of_device_is_compatible(np, pwrseq_match[i].compatible)) {
+ match = pwrseq_match[i];
+ break;
+ }
+ }
+
+ return match;
+}
int mmc_pwrseq_alloc(struct mmc_host *host)
{
- return 0;
+ struct platform_device *pdev;
+ struct device_node *np;
+ struct mmc_pwrseq_match *match;
+ int ret = 0;
+
+ np = of_parse_phandle(host-parent-of_node, mmc-pwrseq, 0);
+ if (!np)
+ return 0;
+
+ pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ ret = -ENODEV;
+ goto err;
+ }
+
+ match = mmc_pwrseq_find(np);
+ if (IS_ERR(match)) {
+ ret = PTR_ERR(match);
+ goto err;
+ }
+
+ ret = match-alloc(host, pdev-dev);
+ if (!ret)
+ dev_info(host-parent, allocated mmc-pwrseq\n);
+
+err:
+ of_node_put(np);
+ return ret;
}
void mmc_pwrseq_pre_power_on(struct mmc_host *host)
diff --git a/drivers/mmc/core/pwrseq.h b/drivers/mmc/core/pwrseq.h
index 12aaf2b..bd860d8 100644
--- a/drivers/mmc/core/pwrseq.h
+++ b/drivers/mmc/core/pwrseq.h
@@ -27,6 +27,8 @@ void mmc_pwrseq_post_power_on(struct mmc_host *host);
void mmc_pwrseq_power_off(struct mmc_host *host);
void mmc_pwrseq_free(struct mmc_host *host);
+int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev);
+
#else
static inline int mmc_pwrseq_alloc(struct mmc_host *host) { return 0; }
diff --git a/drivers/mmc/core/pwrseq_simple.c
b/drivers/mmc/core/pwrseq_simple.c
new file mode 100644
index 000..61c991e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd
+ *
+ * Author: Ulf Hansson ulf.hans...@linaro.org
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ *
+ * Simple MMC power sequence management
+ */
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/device.h
+#include linux/err.h
+
+#include linux/mmc/host.h
+
+#include pwrseq.h
+
+struct mmc_pwrseq_simple {
+ struct mmc_pwrseq pwrseq;
+};
+
+static void mmc_pwrseq_simple_free(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct
Re: [PATCH 1/7] pinctrl: mediatek: emulate GPIO interrupt on both-edges
Hello,
On Tue, Jan 27, 2015 at 02:15:26PM +0800, Chaotian Jing wrote:
From: Yingjoe Chen yingjoe.c...@mediatek.com
MTK EINT does not support generating interrupt on both edges.
Emulate this by changing edge polarity while enable irq,
set types and interrupt handling. This follows an example of
drivers/gpio/gpio-mxc.c.
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
Signed-off-by: Chaotian Jing chaotian.j...@mediatek.com
---
drivers/pinctrl/mediatek/pinctrl-mt8135.c | 3 ++
drivers/pinctrl/mediatek/pinctrl-mt8173.c | 3 ++
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 76
+--
drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 4 ++
4 files changed, 83 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8135.c
b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
index b6ee2b2..1296d6d 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8135.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8135.c
@@ -325,6 +325,9 @@ static const struct mtk_pinctrl_devdata
mt8135_pinctrl_data = {
.sens = 0x140,
.sens_set = 0x180,
.sens_clr = 0x1c0,
+ .soft = 0x200,
+ .soft_set = 0x240,
+ .soft_clr = 0x280,
.pol = 0x300,
.pol_set = 0x340,
.pol_clr = 0x380,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
index 444d88d..717000e 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
@@ -278,6 +278,9 @@ static const struct mtk_pinctrl_devdata
mt8173_pinctrl_data = {
.sens = 0x140,
.sens_set = 0x180,
.sens_clr = 0x1c0,
+ .soft = 0x200,
+ .soft_set = 0x240,
+ .soft_clr = 0x280,
.pol = 0x300,
.pol_set = 0x340,
.pol_clr = 0x380,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 109a882..820ce9e 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -792,6 +792,32 @@ static unsigned int mtk_eint_get_mask(struct mtk_pinctrl
*pctl,
return !!(readl(reg) bit);
}
+static int mtk_eint_flip_edge(struct mtk_pinctrl *pctl, int hwirq)
+{
+ int start_level, curr_level;
+ unsigned int reg_offset;
+ const struct mtk_eint_offsets *eint_offsets =
(pctl-devdata-eint_offsets);
+ u32 mask = 1 (hwirq 0x1f);
+ u32 port = (hwirq 5) eint_offsets-port_mask;
+ void __iomem *reg = pctl-eint_reg_base + (port 2);
+ const struct mtk_desc_pin *pin;
+
+ pin = mtk_find_pin_by_eint_num(pctl, hwirq);
+ curr_level = mtk_gpio_get(pctl-chip, pin-pin.number);
+ do {
+ start_level = curr_level;
+ if (start_level)
+ reg_offset = eint_offsets-pol_clr;
+ else
+ reg_offset = eint_offsets-pol_set;
+ writel(mask, reg + reg_offset);
+
+ curr_level = mtk_gpio_get(pctl-chip, pin-pin.number);
+ } while (start_level != curr_level);
+
+ return start_level;
+}
+
static void mtk_eint_mask(struct irq_data *d)
{
struct mtk_pinctrl *pctl = irq_data_get_irq_chip_data(d);
@@ -814,6 +840,9 @@ static void mtk_eint_unmask(struct irq_data *d)
eint_offsets-mask_clr);
writel(mask, reg);
+
+ if (pctl-eint_dual_edges[d-hwirq])
+ mtk_eint_flip_edge(pctl, d-hwirq);
}
From looking at the code it seems to me that there is a bug. Consider
the following to happen:
pin changes level, say high to low, triggers irq
irq is masked by writel(mask, reg) in mtk_eint_mask
mtk_eint_flip_edge gets curr_level = low
pin goes up
writel(mask, reg + eint_offsets-pol_set);
oh, pin is high, so: writel(mask, reg + eint_offsets-pol_clr
So now you trigger the irq the next time when the pin goes down again.
But that means to missed to trigger on the pin goes up in the above
list, right?
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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/5] usb: phy: load usb phy earlier
On 02/10/2015 03:04 PM, Peter Chen wrote: This patch does not belong to phy, so, doesn't need to add phy in subject, meanwhile, please add GregKH as TO list, he is the right one to queue this patch. Reply-To: In-Reply-To: 1423554627-694-5-git-send-email-zhangfei@linaro.org OK, thanks Peter. Will resend this patchset and drop this one. -- 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
[resend PATCH v3 3/4] usb: dwc2: platform: add hi6220 support
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
drivers/usb/dwc2/platform.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index ae095f0..f7c67db 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -50,6 +50,35 @@
static const char dwc2_driver_name[] = dwc2;
+static const struct dwc2_core_params params_hi6220 = {
+ .otg_cap= 2,/* No HNP/SRP capable */
+ .otg_ver= 0,/* 1.3 */
+ .dma_enable = 1,
+ .dma_desc_enable= 0,
+ .speed = 0,/* High Speed */
+ .enable_dynamic_fifo= 1,
+ .en_multiple_tx_fifo= 1,
+ .host_rx_fifo_size = 512,
+ .host_nperio_tx_fifo_size = 512,
+ .host_perio_tx_fifo_size= 512,
+ .max_transfer_size = 65535,
+ .max_packet_count = 511,
+ .host_channels = 16,
+ .phy_type = 1,/* UTMI */
+ .phy_utmi_width = 8,
+ .phy_ulpi_ddr = 0,/* Single */
+ .phy_ulpi_ext_vbus = 0,
+ .i2c_enable = 0,
+ .ulpi_fs_ls = 0,
+ .host_support_fs_ls_low_power = 0,
+ .host_ls_low_power_phy_clk = 0,/* 48 MHz */
+ .ts_dline = 0,
+ .reload_ctl = 0,
+ .ahbcfg = GAHBCFG_HBSTLEN_INCR16
+ GAHBCFG_HBSTLEN_SHIFT,
+ .uframe_sched = 0,
+};
+
static const struct dwc2_core_params params_bcm2835 = {
.otg_cap= 0,/* HNP/SRP capable */
.otg_ver= 0,/* 1.3 */
@@ -129,6 +158,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = brcm,bcm2835-usb, .data = params_bcm2835 },
+ { .compatible = hisilicon,hi6220-usb, .data = params_hi6220 },
{ .compatible = rockchip,rk3066-usb, .data = params_rk3066 },
{ .compatible = snps,dwc2, .data = NULL },
{ .compatible = samsung,s3c6400-hsotg, .data = NULL},
--
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
[resend PATCH v3 2/4] Documentation: dt-bindings: add dt binding info for hi6220
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
.../devicetree/bindings/usb/hi6220-usb.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/hi6220-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/hi6220-usb.txt
b/Documentation/devicetree/bindings/usb/hi6220-usb.txt
new file mode 100644
index 000..b8278de
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/hi6220-usb.txt
@@ -0,0 +1,49 @@
+Hisilicon hi6220 SoC USB controller
+-
+
+usb controller is inherited from dwc2, refer dwc2.txt
+-
+
+Required properties:
+- compatible: hisilicon,hi6220-usb
+Refer to dwc2.txt for dwc2 usb properties
+
+
+PHY:
+-
+
+Required properties:
+- compatible: hisilicon,hi6220-usb-phy
+- vcc-supply: phandle to the regulator that provides power to the PHY.
+- clocks: phandle and clock specifier of the PHY clock.
+- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral.
+- hisilicon,gpio-vbus: gpio of detecting vbus.
+- hisilicon,gpio-id: gpio of detecting id.
+
+Example:
+
+ peripheral_ctrl: syscon@f703 {
+ compatible = syscon;
+ reg = 0x0 0xf703 0x0 0x1000;
+ };
+
+ usb2_phy: usbphy {
+ compatible = hisilicon,hi6220-usb-phy;
+ vcc-supply = fixed_5v_hub;
+ hisilicon,gpio-vbus = gpio2 6 0;
+ hisilicon,gpio-id = gpio2 5 0;
+ hisilicon,peripheral-syscon = peripheral_ctrl;
+ clocks = clock_sys HI6220_USBOTG_HCLK;
+ };
+
+ usb: usb@f72c {
+ compatible = hisilicon,hi6220-usb;
+ reg = 0x0 0xf72c 0x0 0x4;
+ phys = usb2_phy;
+ dr_mode = otg;
+ g-use-dma;
+ g-rx-fifo-size = 512;
+ g-np-tx-fifo-size = 128;
+ g-tx-fifo-size = 128;
+ interrupts = 0 77 0x4;
+ };
--
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
[resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb
Add usb phy controller for hi6220 platform
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
drivers/usb/phy/Kconfig | 9 ++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/phy-hi6220-usb.c | 306 +++
3 files changed, 316 insertions(+)
create mode 100644 drivers/usb/phy/phy-hi6220-usb.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index c6d0c8e..405a3d0 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -173,6 +173,15 @@ config USB_MXS_PHY
MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x.
+config USB_HI6220_PHY
+ tristate hi6220 USB PHY support
+ select USB_PHY
+ select MFD_SYSCON
+ help
+ Enable this to support the HISILICON HI6220 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
config USB_RCAR_PHY
tristate Renesas R-Car USB PHY support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 75f2bba..00172d3 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
obj-$(CONFIG_TWL6030_USB) += phy-twl6030-usb.o
obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
+obj-$(CONFIG_USB_HI6220_PHY) += phy-hi6220-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
diff --git a/drivers/usb/phy/phy-hi6220-usb.c b/drivers/usb/phy/phy-hi6220-usb.c
new file mode 100644
index 000..efb4bbb
--- /dev/null
+++ b/drivers/usb/phy/phy-hi6220-usb.c
@@ -0,0 +1,306 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon 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.
+ */
+
+#include linux/clk.h
+#include linux/mfd/syscon.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/regulator/consumer.h
+#include linux/usb/gadget.h
+#include linux/usb/otg.h
+
+#define SC_PERIPH_CTRL40x00c
+
+#define CTRL4_PICO_SIDDQ BIT(6)
+#define CTRL4_PICO_OGDISABLE BIT(8)
+#define CTRL4_PICO_VBUSVLDEXT BIT(10)
+#define CTRL4_PICO_VBUSVLDEXTSEL BIT(11)
+#define CTRL4_OTG_PHY_SEL BIT(21)
+
+#define SC_PERIPH_CTRL50x010
+
+#define CTRL5_USBOTG_RES_SEL BIT(3)
+#define CTRL5_PICOPHY_ACAENB BIT(4)
+#define CTRL5_PICOPHY_BC_MODE BIT(5)
+#define CTRL5_PICOPHY_CHRGSEL BIT(6)
+#define CTRL5_PICOPHY_VDATSRCEND BIT(7)
+#define CTRL5_PICOPHY_VDATDETENB BIT(8)
+#define CTRL5_PICOPHY_DCDENB BIT(9)
+#define CTRL5_PICOPHY_IDDIGBIT(10)
+
+#define SC_PERIPH_CTRL80x018
+#define SC_PERIPH_RSTEN0 0x300
+#define SC_PERIPH_RSTDIS0 0x304
+
+#define RST0_USBOTG_BUSBIT(4)
+#define RST0_POR_PICOPHY BIT(5)
+#define RST0_USBOTGBIT(6)
+#define RST0_USBOTG_32KBIT(7)
+
+#define EYE_PATTERN_PARA 0x7053348c
+
+struct hi6220_priv {
+ struct usb_phy phy;
+ struct delayed_work work;
+ struct regmap *reg;
+ struct clk *clk;
+ struct regulator *vcc;
+ struct device *dev;
+ int gpio_vbus;
+ int gpio_id;
+ enum usb_otg_state state;
+};
+
+static void hi6220_start_periphrals(struct hi6220_priv *priv, bool on)
+{
+ struct usb_otg *otg = priv-phy.otg;
+
+ if (!otg-gadget)
+ return;
+
+ if (on)
+ usb_gadget_connect(otg-gadget);
+ else
+ usb_gadget_disconnect(otg-gadget);
+}
+
+static void hi6220_detect_work(struct work_struct *work)
+{
+ struct hi6220_priv *priv =
+ container_of(work, struct hi6220_priv, work.work);
+ int gpio_id, gpio_vbus;
+ enum usb_otg_state state;
+
+ if (!gpio_is_valid(priv-gpio_id) || !gpio_is_valid(priv-gpio_vbus))
+ return;
+
+ gpio_id = gpio_get_value_cansleep(priv-gpio_id);
+ gpio_vbus = gpio_get_value_cansleep(priv-gpio_vbus);
+
+ if (gpio_vbus == 0) {
+ if (gpio_id == 1)
+ state = OTG_STATE_B_PERIPHERAL;
+ else
+ state = OTG_STATE_A_HOST;
+ } else {
+ state = OTG_STATE_A_HOST;
+ }
+
+ if (priv-state != state) {
+ hi6220_start_periphrals(priv, state == OTG_STATE_B_PERIPHERAL);
+ priv-state = state;
+
[resend PATCH v3 1/4] Documentation: dt-bindings: add dt binding info for hi6220 dwc2
Add necessary dwc2 binding documentation for Hisilicon soc: hi6220 Signed-off-by: Zhangfei Gao zhangfei@linaro.org --- Documentation/devicetree/bindings/usb/dwc2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index fd132cb..2213682 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -4,6 +4,7 @@ Platform DesignWare HS OTG USB 2.0 controller Required properties: - compatible : One of: - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC. + - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC. - rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc; - rockchip,rk3188-usb, rockchip,rk3066-usb, snps,dwc2: for rk3188 Soc; - rockchip,rk3288-usb, rockchip,rk3066-usb, snps,dwc2: for rk3288 Soc; -- 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
[resend PATCH v3 0/4] add usb support for hi6220
v3: fix typo and add -EPROBE_DEFER of regulator, pointed by Peter v2: address comments from Sergei and Peter add hi6220_phy_setup(false) code v1: hi6220 usb controller is inherited from dwc2 add phy accordingly support otg gadget/host Zhangfei Gao (4): Documentation: dt-bindings: add dt binding info for hi6220 dwc2 Documentation: dt-bindings: add dt binding info for hi6220 usb: dwc2: platform: add hi6220 support usb: phy: add phy-hi6220-usb Documentation/devicetree/bindings/usb/dwc2.txt | 1 + .../devicetree/bindings/usb/hi6220-usb.txt | 49 drivers/usb/dwc2/platform.c| 30 ++ drivers/usb/phy/Kconfig| 9 + drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-hi6220-usb.c | 306 + 6 files changed, 396 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/hi6220-usb.txt create mode 100644 drivers/usb/phy/phy-hi6220-usb.c -- 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 v5 2/5] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.
On Wed, Jan 21, 2015 at 1:28 PM, Hongzhou Yang hongzhou.y...@mediatek.com wrote: From: Hongzhou Yang hongzhou.y...@mediatek.com Add devicetree bindings for Mediatek SoC pinctrl driver. Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com OK applied this patch for v3.21 now, relying on Sascha's ACK. Yours, Linus Walleij -- 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 v5 5/5] ARM: dts: mt8135: Add pinctrl/GPIO/EINT node for mt8135.
On Wed, Jan 21, 2015 at 1:28 PM, Hongzhou Yang hongzhou.y...@mediatek.com wrote: From: Hongzhou Yang hongzhou.y...@mediatek.com Add pinctrl,GPIO and EINT node to mt8135.dtsi. Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com Acked-by: Linus Walleij linus.wall...@linaro.org The pinctrl driver portions are merged to the pin control tree. Yours, Linus Walleij -- 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 1/2] dt-bindings: add disable-wakeup property for gpio-charger
add disable-wakeup for gpio-charger, if you set this property, system
will not wakeup by gpio-charger.
Signed-off-by: Chris Zhong z...@rock-chips.com
---
Documentation/devicetree/bindings/power_supply/gpio-charger.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
b/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
index adbb5dc..a46e9bc 100644
--- a/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
+++ b/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
@@ -4,6 +4,7 @@ Required properties :
- compatible : gpio-charger
- gpios : GPIO indicating the charger presence.
See GPIO binding in bindings/gpio/gpio.txt .
+ - gpio-charger,disable-wakeup : Boolean, charger does not wake-up the system.
- charger-type : power supply type, one of
unknown
battery
@@ -20,6 +21,7 @@ Example:
compatible = gpio-charger;
charger-type = usb-sdp;
gpios = gpf0 2 0 0 0;
+ gpio-charger,disable-wakeup;
}
battery {
--
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 1/3] arm64: mediatek: Add config option for mt8173.
On Tue, Jan 27, 2015 at 3:13 PM, Hongzhou Yang hongzhou.y...@mediatek.com wrote: From: Hongzhou Yang hongzhou.y...@mediatek.com The upcoming MTK pinctrl driver have a big pin table for each SoC, and we don't want to bloat the kernel binary if we don't need it. Add config options so we can build for one SoC only. Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com Acked-by: Linus Walleij linus.wall...@linaro.org Take this through the ARM SoC tree with the rest of the mediatek SoC stuff. Yours, Linus Walleij -- 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] arm64: mediatek: Add Pinctrl/GPIO/EINT driver for mt8173.
On Tue, Jan 27, 2015 at 3:13 PM, Hongzhou Yang hongzhou.y...@mediatek.com wrote: From: Hongzhou Yang hongzhou.y...@mediatek.com Add mt8173 support using mediatek common pinctrl driver. MT8173 have a different ies_smt setting register than mt8135, so adding this support to common code. Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com Patch applied on top of the base 8135 series. Yours, Linus Walleij -- 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/3] arm64: dts: mt8173: Add pinctrl/GPIO/EINT node for mt8173.
On Tue, Jan 27, 2015 at 3:13 PM, Hongzhou Yang hongzhou.y...@mediatek.com wrote: From: Hongzhou Yang hongzhou.y...@mediatek.com Add pinctrl,GPIO and EINT node to mt8173.dtsi. Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com Acked-by: Linus Walleij linus.wall...@libaro.org Yours, Linus Walleij -- 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/7] pinctrl: mediatek: emulate GPIO interrupt on both-edges
On Tue, Jan 27, 2015 at 2:15 PM, Chaotian Jing chaotian.j...@mediatek.com wrote: From: Yingjoe Chen yingjoe.c...@mediatek.com MTK EINT does not support generating interrupt on both edges. Emulate this by changing edge polarity while enable irq, set types and interrupt handling. This follows an example of drivers/gpio/gpio-mxc.c. Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com Signed-off-by: Chaotian Jing chaotian.j...@mediatek.com Patch applied on top of the rest of the mtk pinctrl support. Adding Hongzhou's ACK on top. Yours, Linus Walleij -- 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/5] usb: phy: load usb phy earlier
This patch does not belong to phy, so, doesn't need to add phy in subject, meanwhile, please add GregKH as TO list, he is the right one to queue this patch. Reply-To: In-Reply-To: 1423554627-694-5-git-send-email-zhangfei@linaro.org On Tue, Feb 10, 2015 at 03:50:26PM +0800, Zhangfei Gao wrote: Since phy is definitely used in usb controller, load the phy earlier to make boot time shorter. Signed-off-by: Zhangfei Gao zhangfei@linaro.org Acked-by: Peter Chen peter.c...@freescale.com --- drivers/usb/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 2f1e2aa..d8926c6 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -5,6 +5,7 @@ # Object files in subdirectories obj-$(CONFIG_USB)+= core/ +obj-$(CONFIG_USB_SUPPORT)+= phy/ obj-$(CONFIG_USB_DWC3) += dwc3/ obj-$(CONFIG_USB_DWC2) += dwc2/ @@ -48,7 +49,6 @@ obj-$(CONFIG_USB_MICROTEK) += image/ obj-$(CONFIG_USB_SERIAL) += serial/ obj-$(CONFIG_USB)+= misc/ -obj-$(CONFIG_USB_SUPPORT)+= phy/ obj-$(CONFIG_EARLY_PRINTK_DBGP) += early/ obj-$(CONFIG_USB_ATM)+= atm/ -- 1.9.1 -- 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] Input: pixcir_i2c_ts - Add RESET gpio
Hi Dmitry,
On 06/02/15 18:54, Dmitry Torokhov wrote:
Hi Roger,
On Fri, Feb 06, 2015 at 02:53:10PM +0200, Roger Quadros wrote:
The controller has a RESET pin which is usually controlled over
a GPIO line. If such a GPIO is provided, perform a RESET
during probe.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../bindings/input/touchscreen/pixcir_i2c_ts.txt | 3 ++
drivers/input/touchscreen/pixcir_i2c_ts.c | 37
--
include/linux/input/pixcir_ts.h| 1 +
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
index 6e55109..8eb240a 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
@@ -8,6 +8,9 @@ Required properties:
- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
- touchscreen-size-y: vertical resolution of touchscreen (in pixels)
+Optional properties:
+- reset-gpio: GPIO connected to the RESET line of the chip
+
Example:
i2c@ {
diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 4fb5537..610ce0b 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -51,6 +51,19 @@ struct pixcir_report_data {
struct pixcir_touch touches[PIXCIR_MAX_SLOTS];
};
+static void pixcir_reset(struct pixcir_i2c_ts_data *tsdata)
+{
+const struct pixcir_ts_platform_data *pdata = tsdata-pdata;
+
+if (gpio_is_valid(pdata-gpio_reset)) {
+gpio_set_value(pdata-gpio_reset, 1);
+ndelay(80);
+gpio_set_value(pdata-gpio_reset, 0);
+/* wait as controller might not immediately respond */
+msleep(100);
+}
+}
+
static void pixcir_ts_parse(struct pixcir_i2c_ts_data *tsdata,
struct pixcir_report_data *report)
{
@@ -428,7 +441,8 @@ static struct pixcir_ts_platform_data
*pixcir_parse_dt(struct device *dev)
pdata-chip = *(const struct pixcir_i2c_chip_data *)match-data;
pdata-gpio_attb = of_get_named_gpio(np, attb-gpio, 0);
-/* gpio_attb validity is checked in probe */
+pdata-gpio_reset = of_get_named_gpio(np, reset-gpio, 0);
+/* gpio validity is checked in probe */
if (of_property_read_u32(np, touchscreen-size-x, pdata-x_max)) {
dev_err(dev, Failed to get touchscreen-size-x property\n);
@@ -442,8 +456,9 @@ static struct pixcir_ts_platform_data
*pixcir_parse_dt(struct device *dev)
}
pdata-y_max -= 1;
-dev_dbg(dev, %s: x %d, y %d, gpio %d\n, __func__,
-pdata-x_max + 1, pdata-y_max + 1, pdata-gpio_attb);
+dev_dbg(dev, %s: x %d, y %d, ATTB gpio %d, RESET gpio %d\n, __func__,
+pdata-x_max + 1, pdata-y_max + 1, pdata-gpio_attb,
+pdata-gpio_reset);
return pdata;
}
@@ -481,6 +496,10 @@ static int pixcir_i2c_ts_probe(struct i2c_client
*client,
return -EINVAL;
}
+/* RESET gpio is optional */
+if (!gpio_is_valid(pdata-gpio_reset))
+dev_info(dev, Invalid gpio_reset in pdata\n);
+
if (!pdata-chip.max_fingers) {
dev_err(dev, Invalid max_fingers in pdata\n);
return -EINVAL;
@@ -530,6 +549,16 @@ static int pixcir_i2c_ts_probe(struct i2c_client
*client,
input_set_drvdata(input, tsdata);
+if (gpio_is_valid(pdata-gpio_reset)) {
+error = devm_gpio_request_one(dev, pdata-gpio_reset,
+ GPIOF_OUT_INIT_LOW,
+ pixcir_i2c_reset);
+if (error) {
+dev_err(dev, Failed to request RESET gpio\n);
+return error;
+}
+}
+
error = devm_gpio_request_one(dev, pdata-gpio_attb,
GPIOF_DIR_IN, pixcir_i2c_attb);
if (error) {
@@ -545,6 +574,8 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client,
return error;
}
+pixcir_reset(tsdata);
+
/* Always be in IDLE mode to save power, device supports auto wake */
error = pixcir_set_power_mode(tsdata, PIXCIR_POWER_IDLE);
if (error) {
diff --git a/include/linux/input/pixcir_ts.h
b/include/linux/input/pixcir_ts.h
index 7bae83b..9e91fd3 100644
--- a/include/linux/input/pixcir_ts.h
+++ b/include/linux/input/pixcir_ts.h
@@ -58,6 +58,7 @@ struct pixcir_ts_platform_data {
int x_max;
int y_max;
int gpio_attb; /* GPIO connected to ATTB line */
+int gpio_reset; /* GPIO connected to RESET line */
struct pixcir_i2c_chip_data chip;
Declaring gpio_reset like this means that non-OF platforms will have
Re: [PATCH v9 2/3] i2c: iproc: Add Broadcom iProc I2C Driver
Thanks, Wolfram. I think I'm missing something here and would like to get it clarified, so I don't make the same mistake again in the future: I thought I've already sent these patches as a new thread, i.e., [PATCH v9 ...], isn't it? Yes, but In-Reply-To was set and so my MUAs (mutt and Thunderbird) threaded them to your first submission. Most people I know prefer to have this not threaded. signature.asc Description: Digital signature
Re: [PATCH 1/7] pinctrl: mediatek: emulate GPIO interrupt on both-edges
On Tue, 2015-02-10 at 09:40 +0100, Uwe Kleine-König wrote:
Hello,
On Tue, Jan 27, 2015 at 02:15:26PM +0800, Chaotian Jing wrote:
From: Yingjoe Chen yingjoe.c...@mediatek.com
MTK EINT does not support generating interrupt on both edges.
Emulate this by changing edge polarity while enable irq,
set types and interrupt handling. This follows an example of
drivers/gpio/gpio-mxc.c.
...
+static int mtk_eint_flip_edge(struct mtk_pinctrl *pctl, int hwirq)
+{
+ int start_level, curr_level;
+ unsigned int reg_offset;
+ const struct mtk_eint_offsets *eint_offsets =
(pctl-devdata-eint_offsets);
+ u32 mask = 1 (hwirq 0x1f);
+ u32 port = (hwirq 5) eint_offsets-port_mask;
+ void __iomem *reg = pctl-eint_reg_base + (port 2);
+ const struct mtk_desc_pin *pin;
+
+ pin = mtk_find_pin_by_eint_num(pctl, hwirq);
+ curr_level = mtk_gpio_get(pctl-chip, pin-pin.number);
+ do {
+ start_level = curr_level;
+ if (start_level)
+ reg_offset = eint_offsets-pol_clr;
+ else
+ reg_offset = eint_offsets-pol_set;
+ writel(mask, reg + reg_offset);
+
+ curr_level = mtk_gpio_get(pctl-chip, pin-pin.number);
+ } while (start_level != curr_level);
+
+ return start_level;
+}
+
static void mtk_eint_mask(struct irq_data *d)
{
struct mtk_pinctrl *pctl = irq_data_get_irq_chip_data(d);
@@ -814,6 +840,9 @@ static void mtk_eint_unmask(struct irq_data *d)
eint_offsets-mask_clr);
writel(mask, reg);
+
+ if (pctl-eint_dual_edges[d-hwirq])
+ mtk_eint_flip_edge(pctl, d-hwirq);
}
From looking at the code it seems to me that there is a bug. Consider
the following to happen:
pin changes level, say high to low, triggers irq
irq is masked by writel(mask, reg) in mtk_eint_mask
mtk_eint_flip_edge gets curr_level = low
pin goes up
writel(mask, reg + eint_offsets-pol_set);
oh, pin is high, so: writel(mask, reg + eint_offsets-pol_clr
So now you trigger the irq the next time when the pin goes down again.
But that means to missed to trigger on the pin goes up in the above
list, right?
Hi Uwe,
Yes, this could be a problem when irq happen. So I fix/workaround this
in mtk_eint_irq_handler() using soft-irq. When this bit is set, eint
will trigger the same interrupt again.
+ if (dual_edges) {
+ curr_level = mtk_eint_flip_edge(pctl, index);
+
+ /* If level changed, we might lost one edge
+ interrupt, raised it through soft-irq */
+ if (start_level != curr_level)
+ writel(BIT(offset), reg -
+ eint_offsets-stat +
+ eint_offsets-soft_set);
+ }
Joe.C
--
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 v5 3/5] ARM: mediatek: Add Pinctrl/GPIO driver for mt8135.
On Wed, Jan 21, 2015 at 1:28 PM, Hongzhou Yang hongzhou.y...@mediatek.com wrote: From: Hongzhou Yang hongzhou.y...@mediatek.com The mediatek SoCs have GPIO controller that handle both the muxing and GPIOs. The GPIO controller have pinmux, pull enable, pull select, direction and output high/low control. This driver include common driver and mt8135 part. The common driver include the pinctrl driver and GPIO driver. The mt8135 part contain its special device data. Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com I have merged this patch for v3.21, except: arch/arm/mach-mediatek/Kconfig|1 + (...) --- a/arch/arm/mach-mediatek/Kconfig +++ b/arch/arm/mach-mediatek/Kconfig @@ -1,6 +1,7 @@ menuconfig ARCH_MEDIATEK bool Mediatek MT65xx MT81xx SoC if ARCH_MULTI_V7 select ARM_GIC + select PINCTRL select MTK_TIMER help Support for Mediatek MT65xx MT81xx SoCs This, which should come in through the ARM SoC tree. It's not dependent on this series anyway. This will appear after the merge window as we start the v3.21 cycle. Yours, Linus Walleij -- 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 4/4] mmc: pwrseq_simple: Add support for a reset GPIO pin
On Mon, Jan 19, 2015 at 6:13 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
The need for reset GPIOs has several times been pointed out from
erlier posted patchsets. Especially some WLAN chips which are
attached to an SDIO interface may use a GPIO reset.
The reset GPIO is asserted at initialization and prior we start the
power up procedure. The GPIO will be de-asserted right after the power
has been provided to the card, from the -post_power_on() callback.
Note, the reset GPIO is optional. Thus we don't return an error even if
we can't find a GPIO for the consumer.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Excellent, with this I can probe the wifi chip on NVIDIA SHIELD which
requires a GPIO to be high for reset to be de-asserted.
The series:
Tested-by: Alexandre Courbot acour...@nvidia.com
---
Changes in v4:
- Fixed call to kfree().
---
drivers/mmc/core/pwrseq_simple.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/mmc/core/pwrseq_simple.c
b/drivers/mmc/core/pwrseq_simple.c
index 61c991e..0958c69 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
#include linux/slab.h
#include linux/device.h
#include linux/err.h
+#include linux/gpio/consumer.h
#include linux/mmc/host.h
@@ -18,31 +19,68 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
};
+static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ if (!IS_ERR(pwrseq-reset_gpio))
+ gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+}
+
+static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ if (!IS_ERR(pwrseq-reset_gpio))
+ gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+}
+
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ if (!IS_ERR(pwrseq-reset_gpio))
+ gpiod_put(pwrseq-reset_gpio);
+
kfree(pwrseq);
host-pwrseq = NULL;
}
static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
+ .pre_power_on = mmc_pwrseq_simple_pre_power_on,
+ .post_power_on = mmc_pwrseq_simple_post_power_on,
+ .power_off = mmc_pwrseq_simple_pre_power_on,
.free = mmc_pwrseq_simple_free,
};
int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
{
struct mmc_pwrseq_simple *pwrseq;
+ int ret = 0;
pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;
+ pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
gpiod_get() will translate to exactly the same, with less characters.
Actually I see that the version in -next has support for multiple
GPIOs. You will probably want to look at Rojhalat's latest work on
GPIO arrays:
http://permalink.gmane.org/gmane.linux.kernel.gpio/6126
This code would be a great candidate to use this GPIO array API, but
since it is not in -next yet (should happen soon though) you might
want to consider doing it later.
Btw, I wasted a considerable amount of time on one of the defunct
previous attempts at power sequences, so I'm interested in reviewing
future versions of this patchset if you don't mind adding me to the CC
list. :)
--
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 v5 0/4] media: ov2640: add device tree support
This patch series add device tree support for ov2640. And also add the document for the devicetree properties. v4-v5: 1. based on soc-camera v4l2-clk changes. 2. remove the master_clk related (one commit), we only have one clk. v3-v4: 1. refined the dt document. 2. Add Laurent's acked-by. v2-v3: 1. fix the gpiod_xxx api usage as we use reset pin as ACTIVE_LOW. 2. update the devicetree binding document. v1 - v2: 1. modified the dt bindings according to Laurent's suggestion. 2. add a fix patch for soc_camera. Otherwise the .reset() function won't work. Josh Wu (4): media: soc-camera: use icd-control instead of icd-pdev for reset() media: ov2640: add async probe function media: ov2640: add primary dt support media: ov2640: dt: add the device tree binding document .../devicetree/bindings/media/i2c/ov2640.txt | 46 drivers/media/i2c/soc_camera/ov2640.c | 117 ++--- drivers/media/platform/soc_camera/soc_camera.c | 8 +- 3 files changed, 152 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt -- 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 v5 2/4] media: ov2640: add async probe function
In async probe, there is a case that ov2640 is probed before the
host device which provided 'mclk'.
To support this async probe, we will get 'mclk' at first in the probe(),
if failed it will return -EPROBE_DEFER. That will let ov2640 wait for
the host device probed.
Signed-off-by: Josh Wu josh...@atmel.com
---
Changes in v5:
- don't change the ov2640_s_power() code.
- will get 'mclk' at the beginning of ov2640_probe().
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/media/i2c/soc_camera/ov2640.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..057dd49 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -1068,6 +1068,10 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
+ priv-clk = v4l2_clk_get(client-dev, mclk);
+ if (IS_ERR(priv-clk))
+ return -EPROBE_DEFER;
+
v4l2_i2c_subdev_init(priv-subdev, client, ov2640_subdev_ops);
v4l2_ctrl_handler_init(priv-hdl, 2);
v4l2_ctrl_new_std(priv-hdl, ov2640_ctrl_ops,
@@ -1075,24 +1079,28 @@ static int ov2640_probe(struct i2c_client *client,
v4l2_ctrl_new_std(priv-hdl, ov2640_ctrl_ops,
V4L2_CID_HFLIP, 0, 1, 1, 0);
priv-subdev.ctrl_handler = priv-hdl;
- if (priv-hdl.error)
- return priv-hdl.error;
-
- priv-clk = v4l2_clk_get(client-dev, mclk);
- if (IS_ERR(priv-clk)) {
- ret = PTR_ERR(priv-clk);
- goto eclkget;
+ if (priv-hdl.error) {
+ ret = priv-hdl.error;
+ goto err_clk;
}
ret = ov2640_video_probe(client);
if (ret) {
- v4l2_clk_put(priv-clk);
-eclkget:
- v4l2_ctrl_handler_free(priv-hdl);
+ goto err_videoprobe;
} else {
dev_info(adapter-dev, OV2640 Probed\n);
}
+ ret = v4l2_async_register_subdev(priv-subdev);
+ if (ret 0)
+ goto err_videoprobe;
+
+ return 0;
+
+err_videoprobe:
+ v4l2_ctrl_handler_free(priv-hdl);
+err_clk:
+ v4l2_clk_put(priv-clk);
return ret;
}
@@ -1100,6 +1108,7 @@ static int ov2640_remove(struct i2c_client *client)
{
struct ov2640_priv *priv = to_ov2640(client);
+ v4l2_async_unregister_subdev(priv-subdev);
v4l2_clk_put(priv-clk);
v4l2_device_unregister_subdev(priv-subdev);
v4l2_ctrl_handler_free(priv-hdl);
--
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] ARM: shmobile: r8a73a4: Move pfc node to work around probe ordering bug
On Mon, Feb 9, 2015 at 7:29 PM, Tony Lindgren t...@atomide.com wrote:
* Geert Uytterhoeven ge...@linux-m68k.org [150209 09:17]:
On Mon, Feb 9, 2015 at 5:24 PM, Tony Lindgren t...@atomide.com wrote:
* Geert Uytterhoeven geert+rene...@glider.be [150206 12:26]:
Notes:
- It seems several people tried to solve this in the core OF probing
code before, but the final solution never went in?
- This can be reproduced on other SoCs (e.g. sh73a0 and r8a7740) by
moving their pfc nodes before their interrupt controller nodes.
- This patch is against my working tree, so it doesn't apply to
Simon's repository, but you get the idea
No issues with the patch, but here are few comments on the core
reasons (without looking at the code in this case) that might help
fix similar issues.
In all the cases I've seen these errors are caused by non-standard
custom initcall levels for drivers like i2c bus. The real solution
is to initialize drivers later with standard module_init, and stop
the race to the bottom with custom initcall levels.
If there is legacy board specific platofrm init code that needs
i2c gpios early, that code can probably be moved to initialize
later on.
In this case no i2c is involved. The drivers for both pinctrl
(renesas,pfc-r8a73a4) and irqchip (renesas,irqc) are registered
at the same level:
- postcore_initcall(sh_pfc_init);
- postcore_initcall(irqc_init);
Hence the system uses the natural order from within the DTS,
and decided to instantiate the pfc before the irqchip.
OK
I tried converting the renesas,irqc driver to IRQCHIP_DECLARE().
This solves the probe ordering problem, but it no longer allows the use of
a platform device. As I was already adding clock and runtime PM support
(which use platform devices), IRQCHIP_DECLARE doesn't look like the
right road to follow...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 v5 4/4] media: ov2640: dt: add the device tree binding document
Add the document for ov2640 dt.
Cc: devicetree@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes in v5: None
Changes in v4:
- remove aggsigned-clocks as it's general.
- refine the explation.
Changes in v3:
- fix incorrect description.
- Add assigned-clocks assigned-clock-rates.
- resetb pin should be ACTIVE_LOW.
Changes in v2:
- change the compatible string to be consistent with verdor file.
- change the clock and pins' name.
- add missed pinctrl in example.
.../devicetree/bindings/media/i2c/ov2640.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
new file mode 100644
index 000..c429b5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
@@ -0,0 +1,46 @@
+* Omnivision OV2640 CMOS sensor
+
+The Omnivision OV2640 sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties:
+- compatible: should be ovti,ov2640
+- clocks: reference to the xvclk input clock.
+- clock-names: should be xvclk.
+
+Optional Properties:
+- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
+- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = ovti,ov2640;
+ reg = 0x30;
+
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_pck1 pinctrl_ov2640_pwdn
pinctrl_ov2640_resetb;
+
+ resetb-gpios = pioE 24 GPIO_ACTIVE_LOW;
+ pwdn-gpios = pioE 29 GPIO_ACTIVE_HIGH;
+
+ clocks = pck1;
+ clock-names = xvclk;
+
+ assigned-clocks = pck1;
+ assigned-clock-rates = 2500;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = isi_0;
+ bus-width = 8;
+ };
+ };
+ };
+ };
--
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 1/4] usb: renesas_usbhs: fix spinlock recursion by usbhsf_dma_complete()
Hi Shimoda-san,
On Mon, Feb 9, 2015 at 9:16 AM, Yoshihiro Shimoda
yoshihiro.shimoda...@renesas.com wrote:
The usbhsf_pkt_handler(pipe, USBHSF_PKT_DMA_DONE) in usbhsf_dma_complete()
will call the complete function of a usb gadget driver finally.
According to the gadget.h, The function will always be called with
interrupts disabled.
So, this patch adds a local_irq_save/local_irq_restore in the
usbhsf_dma_complete() because a dmaengine driver may call this
callback function when interrupts enabled (e.g. in tasklet).
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
drivers/usb/renesas_usbhs/fifo.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/fifo.c
b/drivers/usb/renesas_usbhs/fifo.c
index d891bff..b1440d0 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -1165,11 +1165,14 @@ static void usbhsf_dma_complete(void *arg)
struct usbhs_priv *priv = usbhs_pipe_to_priv(pipe);
struct device *dev = usbhs_priv_to_dev(priv);
int ret;
+ unsigned long flags;
+ local_irq_save(flags);
Adding local_irq_save() without a spinlock is usually not correct.
I'm a bit confused here. usbhsf_pkt_handler() itself calls
usbhs_lock(priv, flags);
which is actually
spin_lock_irqsave(usbhs_priv_to_lock(priv), flags)
so it does disable interrupts internally?
Or is this about protecting the call to
pkt-done(priv, pkt);
at the end of usbhsf_pkt_handler(), which is done after releasing the
spinlock?
Still, that would need some better protection, as local_irq_save() disables
interrupts only on the CPU it's running on, not on other CPUs in a
multiprocessor system.
ret = usbhsf_pkt_handler(pipe, USBHSF_PKT_DMA_DONE);
if (ret 0)
dev_err(dev, dma_complete run_error %d : %d\n,
usbhs_pipe_number(pipe), ret);
+ local_irq_restore(flags);
}
void usbhs_fifo_clear_dcp(struct usbhs_pipe *pipe)
--
1.7.9.5
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 4/4] usb: renesas_usbhs: add support for USB-DMAC
Hi Shimoda-san,
On Mon, Feb 9, 2015 at 9:16 AM, Yoshihiro Shimoda
yoshihiro.shimoda...@renesas.com wrote:
Some Renesas SoCs have the USB-DMAC. It is able to terminate transfers
when a short packet is received, even if less bytes than the transfer
counter size have been received. Also, it is able to send a short
packet even if the packet size is not multiples of 8bytes.
Since the previous code has used the interruption of USBHS controller
when receiving packets even if this driver has used a dmac, a lot of
interruptions has happened. This patch will reduce such interruptions.
This patch allows to use the USB-DMAC on R-Car H2 and M2.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -487,6 +497,15 @@ static struct renesas_usbhs_platform_info
*usbhs_parse_dt(struct device *dev)
if (gpio 0)
dparam-enable_gpio = gpio;
+ switch (dparam-type) {
+ case USBHS_TYPE_R8A7790:
+ case USBHS_TYPE_R8A7791:
+ dparam-has_usb_dmac = 1;
+ break;
+ default:
+ break;
+ }
+
return info;
}
struct usbhs_priv *usbhs_pdev_to_priv(struct platform_device *pdev);
diff --git a/drivers/usb/renesas_usbhs/fifo.c
b/drivers/usb/renesas_usbhs/fifo.c
index 3b77a1b..1e7dc6e 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -847,10 +849,13 @@ static int usbhsf_dma_prepare_push(struct usbhs_pkt
*pkt, int *is_done)
usbhs_pipe_is_dcp(pipe))
goto usbhsf_pio_prepare_push;
- if (len 0x7) /* 8byte alignment */
+ /* default: 8byte alignment */
+ if (!usbhs_get_dparam(priv, has_usb_dmac) len 0x7)
goto usbhsf_pio_prepare_push;
So the has_usb_dmac flags indicates that DMA addresses are not limited to
8-byte alignment.
Can't this be handled by looking at a dma_mask, as set by the DMAC?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 v5 3/4] media: ov2640: add primary dt support
Add device tree support for ov2640.
In device tree, user needs to provide the master clock (xvclk).
User can add the reset/pwdn pins if they have.
Cc: devicetree@vger.kernel.org
Signed-off-by: Josh Wu josh...@atmel.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Changes in v5:
- change the 'mclk' to 'xvclk'. As v4l2-clk will handle the CCF xvclk
and v4l2 master clock internally.
Changes in v4:
- modify the code comment.
- Add Laurent's acked by.
Changes in v3:
- fix gpiod usage.
- refine the ov2640_probe() function.
Changes in v2:
- use gpiod APIs.
- change the gpio pin's name according to datasheet.
- reduce the delay for .reset() function.
drivers/media/i2c/soc_camera/ov2640.c | 90 ---
1 file changed, 83 insertions(+), 7 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 057dd49..c70e9e7 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -18,6 +18,8 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/delay.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#include linux/v4l2-mediabus.h
#include linux/videodev2.h
@@ -283,6 +285,10 @@ struct ov2640_priv {
u32 cfmt_code;
struct v4l2_clk *clk;
const struct ov2640_win_size*win;
+
+ struct soc_camera_subdev_desc ssdd_dt;
+ struct gpio_desc *resetb_gpio;
+ struct gpio_desc *pwdn_gpio;
};
/*
@@ -1038,6 +1044,63 @@ static struct v4l2_subdev_ops ov2640_subdev_ops = {
.video = ov2640_subdev_video_ops,
};
+/* OF probe functions */
+static int ov2640_hw_power(struct device *dev, int on)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ dev_dbg(client-dev, %s: %s the camera\n,
+ __func__, on ? ENABLE : DISABLE);
+
+ if (priv-pwdn_gpio)
+ gpiod_direction_output(priv-pwdn_gpio, !on);
+
+ return 0;
+}
+
+static int ov2640_hw_reset(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ if (priv-resetb_gpio) {
+ /* Active the resetb pin to perform a reset pulse */
+ gpiod_direction_output(priv-resetb_gpio, 1);
+ usleep_range(3000, 5000);
+ gpiod_direction_output(priv-resetb_gpio, 0);
+ }
+
+ return 0;
+}
+
+static int ov2640_probe_dt(struct i2c_client *client,
+ struct ov2640_priv *priv)
+{
+ /* Request the reset GPIO deasserted */
+ priv-resetb_gpio = devm_gpiod_get_optional(client-dev, resetb,
+ GPIOD_OUT_LOW);
+ if (!priv-resetb_gpio)
+ dev_dbg(client-dev, resetb gpio is not assigned!\n);
+ else if (IS_ERR(priv-resetb_gpio))
+ return PTR_ERR(priv-resetb_gpio);
+
+ /* Request the power down GPIO asserted */
+ priv-pwdn_gpio = devm_gpiod_get_optional(client-dev, pwdn,
+ GPIOD_OUT_HIGH);
+ if (!priv-pwdn_gpio)
+ dev_dbg(client-dev, pwdn gpio is not assigned!\n);
+ else if (IS_ERR(priv-pwdn_gpio))
+ return PTR_ERR(priv-pwdn_gpio);
+
+ /* Initialize the soc_camera_subdev_desc */
+ priv-ssdd_dt.power = ov2640_hw_power;
+ priv-ssdd_dt.reset = ov2640_hw_reset;
+ client-dev.platform_data = priv-ssdd_dt;
+
+ return 0;
+}
+
/*
* i2c_driver functions
*/
@@ -1049,12 +1112,6 @@ static int ov2640_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
int ret;
- if (!ssdd) {
- dev_err(adapter-dev,
- OV2640: Missing platform_data for driver\n);
- return -EINVAL;
- }
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(adapter-dev,
OV2640: I2C-Adapter doesn't support SMBUS\n);
@@ -1068,10 +1125,22 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
- priv-clk = v4l2_clk_get(client-dev, mclk);
+ priv-clk = v4l2_clk_get(client-dev, xvclk);
if (IS_ERR(priv-clk))
return -EPROBE_DEFER;
+ if (!ssdd !client-dev.of_node) {
+ dev_err(client-dev, Missing platform_data for driver\n);
+ ret = -EINVAL;
+ goto err_clk;
+ }
+
+ if (!ssdd) {
+ ret = ov2640_probe_dt(client, priv);
+ if (ret)
+ goto err_clk;
+ }
+
v4l2_i2c_subdev_init(priv-subdev, client, ov2640_subdev_ops);
v4l2_ctrl_handler_init(priv-hdl, 2);
v4l2_ctrl_new_std(priv-hdl, ov2640_ctrl_ops,
@@ -1121,9 +1190,16 @@ static const struct i2c_device_id ov2640_id[] = {
};
[PATCH v5 1/4] media: soc-camera: use icd-control instead of icd-pdev for reset()
icd-control is the sub device dev, i.e. i2c device.
icd-pdev is the soc camera device's device.
To be consitent with power() function, we will call reset() with
icd-control as well.
Signed-off-by: Josh Wu josh...@atmel.com
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/media/platform/soc_camera/soc_camera.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..7e6b914 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -688,7 +688,8 @@ static int soc_camera_open(struct file *file)
/* The camera could have been already on, try to reset */
if (sdesc-subdev_desc.reset)
- sdesc-subdev_desc.reset(icd-pdev);
+ if (icd-control)
+ sdesc-subdev_desc.reset(icd-control);
ret = soc_camera_add_device(icd);
if (ret 0) {
@@ -1175,7 +1176,8 @@ static void scan_add_host(struct soc_camera_host *ici)
/* The camera could have been already on, try to reset
*/
if (ssdd-reset)
- ssdd-reset(icd-pdev);
+ if (icd-control)
+ ssdd-reset(icd-control);
icd-parent = ici-v4l2_dev.dev;
@@ -1461,7 +1463,7 @@ static int soc_camera_async_bound(struct
v4l2_async_notifier *notifier,
memcpy(sdesc-subdev_desc, ssdd,
sizeof(sdesc-subdev_desc));
if (ssdd-reset)
- ssdd-reset(icd-pdev);
+ ssdd-reset(client-dev);
}
icd-control = client-dev;
--
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] mmc: dw_mmc: fix bug that cause mmc_test failture
Hi Addy, On Mon, Jan 26, 2015 at 4:04 AM, Addy Ke addy...@rock-chips.com wrote: The STOP command can terminate a data transfer between a memory card and mmc controller. As show in Synopsys DesignWare Cores Mobile Stroage Host Databook: Data timeout and Data end-bit error will terminate further data transfer by mmc controller. So we should not send abort command to terminate a data transfer again if we got DRTO and EBE interrupt. After this patch, all mmc_test cases can pass on RK3288-Pink2 board. Signed-off-by: Addy Ke addy...@rock-chips.com The drawback of having so many people on your to: list on a patch is that it's unclear who you want to review and merge it. Sometimes less is more. In this case, it seems appropriate to have Ulf do so. Ulf, ping? This seems like a reasonable patch for 3.20 given that it fixes undesired behavior. -Olof -- 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: add disable-wakeup property for gpio-charger
On Tue, Feb 10, 2015 at 08:12:24AM +, Chris Zhong wrote:
add disable-wakeup for gpio-charger, if you set this property, system
will not wakeup by gpio-charger.
Signed-off-by: Chris Zhong z...@rock-chips.com
---
Documentation/devicetree/bindings/power_supply/gpio-charger.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
b/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
index adbb5dc..a46e9bc 100644
--- a/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
+++ b/Documentation/devicetree/bindings/power_supply/gpio-charger.txt
@@ -4,6 +4,7 @@ Required properties :
- compatible : gpio-charger
- gpios : GPIO indicating the charger presence.
See GPIO binding in bindings/gpio/gpio.txt .
+ - gpio-charger,disable-wakeup : Boolean, charger does not wake-up the
system.
When would the system wake up otherwise?
Also, gpio-charger is not a vendor prefix.
Mark.
- charger-type : power supply type, one of
unknown
battery
@@ -20,6 +21,7 @@ Example:
compatible = gpio-charger;
charger-type = usb-sdp;
gpios = gpf0 2 0 0 0;
+ gpio-charger,disable-wakeup;
}
battery {
--
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 1/2] dt-bindings: add disable-wakeup property for gpio-charger
Am Dienstag, 10. Februar 2015, 12:00:30 schrieb Mark Rutland: On Tue, Feb 10, 2015 at 08:12:24AM +, Chris Zhong wrote: add disable-wakeup for gpio-charger, if you set this property, system will not wakeup by gpio-charger. Signed-off-by: Chris Zhong z...@rock-chips.com --- Documentation/devicetree/bindings/power_supply/gpio-charger.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/power_supply/gpio-charger.txt b/Documentation/devicetree/bindings/power_supply/gpio-charger.txt index adbb5dc..a46e9bc 100644 --- a/Documentation/devicetree/bindings/power_supply/gpio-charger.txt +++ b/Documentation/devicetree/bindings/power_supply/gpio-charger.txt @@ -4,6 +4,7 @@ Required properties : - compatible : gpio-charger - gpios : GPIO indicating the charger presence. See GPIO binding in bindings/gpio/gpio.txt . + - gpio-charger,disable-wakeup : Boolean, charger does not wake-up the system. When would the system wake up otherwise? a response for patch 2/2 suggested to move this to userspace (as deciding if the charger should be a wakeup source is not a hardware property) and Chris responded that he'll try to move it as suggested. 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
[RESEND PATCH 0/6] Add support for the WM8280 and WM8281
This set of patches adds support for the WM8280 and WM8281 codecs to the Wolfson Arizona drivers. Just another resend on this series, if it would expedite the process I would be happy if we could just merge the MFD patches then I can push the other patches through their respective trees once that hits mainline, but at the moment all the patches are gated by a build dependency on the MFD patches. Thanks, Charles Richard Fitzgerald (6): mfd: arizona: Add support for WM8280/WM8281 Documentation: devicetree: arizona: Add bindings for WM8280 regulator: arizona-micsupp: Add support for WM8280/WM8281 gpio: arizona: Add support for WM8280/WM8281 extcon: arizona: Add support for WM8280/WM8281 ASoC: arizona: Add support for WM8280/WM8281 Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++ drivers/extcon/extcon-arizona.c |1 + drivers/gpio/gpio-arizona.c |1 + drivers/mfd/Kconfig |5 +++-- drivers/mfd/arizona-core.c| 15 +-- drivers/mfd/arizona-i2c.c |2 ++ drivers/mfd/arizona-irq.c |1 + drivers/mfd/arizona-spi.c |2 ++ drivers/regulator/arizona-micsupp.c |1 + include/linux/mfd/arizona/core.h |1 + sound/soc/codecs/arizona.c|2 ++ 11 files changed, 38 insertions(+), 8 deletions(-) -- 1.7.2.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
[RESEND PATCH 6/6] ASoC: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Acked-by: Mark Brown broo...@kernel.org
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
sound/soc/codecs/arizona.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 9550d74..55b5e22 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -281,6 +281,7 @@ int arizona_init_gpio(struct snd_soc_codec *codec)
switch (arizona-type) {
case WM5110:
+ case WM8280:
snd_soc_dapm_disable_pin(codec-dapm, DRC2 Signal Activity);
break;
default:
@@ -1669,6 +1670,7 @@ static int arizona_calc_fratio(struct arizona_fll *fll,
switch (fll-arizona-type) {
case WM5110:
+ case WM8280:
if (fll-arizona-rev 3 || sync)
return init_ratio;
break;
--
1.7.2.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
[RESEND PATCH 2/6] Documentation: devicetree: arizona: Add bindings for WM8280
From: Richard Fitzgerald r...@opensource.wolfsonmicro.com Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 7bd1273..87c878b 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -8,6 +8,7 @@ Required properties: - compatible : One of the following chip-specific strings: wlf,wm5102 wlf,wm5110 +wlf,wm8280 wlf,wm8997 - reg : I2C slave address when connected using I2C, chip select number when using SPI. @@ -26,10 +27,16 @@ Required properties: - #gpio-cells : Must be 2. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). - - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110), -CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, -wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered -in Documentation/devicetree/bindings/regulator/regulator.txt + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, +as covered in Documentation/devicetree/bindings/regulator/regulator.txt + + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, +wm5110, wm8280) + + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, +wm5110, wm8280) + + - SPKVDD-supply : Speaker driver power supply (wm8997) Optional properties: -- 1.7.2.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
[RESEND PATCH 1/6] mfd: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald r...@opensource.wolfsonmicro.com
This adds support for the Wolfson Microelectronics WM8280 and WM8281
codecs.
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Acked-by: Lee Jones lee.jo...@linaro.org
[ Minor fixup to remove potentially uninitialised variable. ]
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/mfd/Kconfig |5 +++--
drivers/mfd/arizona-core.c | 15 +--
drivers/mfd/arizona-i2c.c|2 ++
drivers/mfd/arizona-irq.c|1 +
drivers/mfd/arizona-spi.c|2 ++
include/linux/mfd/arizona/core.h |1 +
6 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 38356e3..9b5e605 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1289,10 +1289,11 @@ config MFD_WM5102
Support for Wolfson Microelectronics WM5102 low power audio SoC
config MFD_WM5110
- bool Wolfson Microelectronics WM5110
+ bool Wolfson Microelectronics WM5110 and WM8280/WM8281
depends on MFD_ARIZONA
help
- Support for Wolfson Microelectronics WM5110 low power audio SoC
+ Support for Wolfson Microelectronics WM5110 and WM8280/WM8281
+ low power audio SoC
config MFD_WM8997
bool Wolfson Microelectronics WM8997
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 09ba8f1..9f81998 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -567,6 +567,7 @@ static int arizona_of_get_core_pdata(struct arizona
*arizona)
const struct of_device_id arizona_of_match[] = {
{ .compatible = wlf,wm5102, .data = (void *)WM5102 },
{ .compatible = wlf,wm5110, .data = (void *)WM5110 },
+ { .compatible = wlf,wm8280, .data = (void *)WM8280 },
{ .compatible = wlf,wm8997, .data = (void *)WM8997 },
{},
};
@@ -671,6 +672,7 @@ int arizona_dev_init(struct arizona *arizona)
switch (arizona-type) {
case WM5102:
case WM5110:
+ case WM8280:
case WM8997:
for (i = 0; i ARRAY_SIZE(wm5102_core_supplies); i++)
arizona-core_supplies[i].supply
@@ -834,11 +836,19 @@ int arizona_dev_init(struct arizona *arizona)
#endif
#ifdef CONFIG_MFD_WM5110
case 0x5110:
- type_name = WM5110;
- if (arizona-type != WM5110) {
+ switch (arizona-type) {
+ case WM5110:
+ type_name = WM5110;
+ break;
+ case WM8280:
+ type_name = WM8280;
+ break;
+ default:
+ type_name = WM5110;
dev_err(arizona-dev, WM5110 registered as %d\n,
arizona-type);
arizona-type = WM5110;
+ break;
}
apply_patch = wm5110_patch;
break;
@@ -1010,6 +1020,7 @@ int arizona_dev_init(struct arizona *arizona)
ARRAY_SIZE(wm5102_devs), NULL, 0, NULL);
break;
case WM5110:
+ case WM8280:
ret = mfd_add_devices(arizona-dev, -1, wm5110_devs,
ARRAY_SIZE(wm5110_devs), NULL, 0, NULL);
break;
diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c
index 9d4156f..ff782a5d 100644
--- a/drivers/mfd/arizona-i2c.c
+++ b/drivers/mfd/arizona-i2c.c
@@ -44,6 +44,7 @@ static int arizona_i2c_probe(struct i2c_client *i2c,
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
regmap_config = wm5110_i2c_regmap;
break;
#endif
@@ -87,6 +88,7 @@ static int arizona_i2c_remove(struct i2c_client *i2c)
static const struct i2c_device_id arizona_i2c_id[] = {
{ wm5102, WM5102 },
{ wm5110, WM5110 },
+ { wm8280, WM8280 },
{ wm8997, WM8997 },
{ }
};
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 3a3fe7c..d063b94 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -211,6 +211,7 @@ int arizona_irq_init(struct arizona *arizona)
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
aod = wm5110_aod;
switch (arizona-rev) {
diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
index 8ef58bc..1e845f6 100644
--- a/drivers/mfd/arizona-spi.c
+++ b/drivers/mfd/arizona-spi.c
@@ -44,6 +44,7 @@ static int arizona_spi_probe(struct spi_device *spi)
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
regmap_config = wm5110_spi_regmap;
break;
#endif
@@ -84,6 +85,7 @@ static int arizona_spi_remove(struct spi_device *spi)
static const struct spi_device_id arizona_spi_ids[] = {
{ wm5102,
Re: [resend PATCH v3 2/4] Documentation: dt-bindings: add dt binding info for hi6220
Hello.
On 2/10/2015 12:10 PM, Zhangfei Gao wrote:
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
.../devicetree/bindings/usb/hi6220-usb.txt | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/hi6220-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/hi6220-usb.txt
b/Documentation/devicetree/bindings/usb/hi6220-usb.txt
new file mode 100644
index 000..b8278de
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/hi6220-usb.txt
@@ -0,0 +1,49 @@
+Hisilicon hi6220 SoC USB controller
+-
[...]
+PHY:
+-
+
+Required properties:
+- compatible: hisilicon,hi6220-usb-phy
+- vcc-supply: phandle to the regulator that provides power to the PHY.
+- clocks: phandle and clock specifier of the PHY clock.
+- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral.
+- hisilicon,gpio-vbus: gpio of detecting vbus.
+- hisilicon,gpio-id: gpio of detecting id.
Actually, GPIO bindings say that GPIO properties should be named
[name-]gpios.
+
+Example:
+
+ peripheral_ctrl: syscon@f703 {
+ compatible = syscon;
+ reg = 0x0 0xf703 0x0 0x1000;
+ };
+
+ usb2_phy: usbphy {
Please name it usb-phy as it better resembles ethernet-phy
standardized by ePAPR.
[...]
WBR, Sergei
--
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
[RESEND PATCH 5/6] extcon: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Acked-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/extcon/extcon-arizona.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 63f01c4..6b5e795 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1149,6 +1149,7 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
}
break;
case WM5110:
+ case WM8280:
switch (arizona-rev) {
case 0 ... 2:
break;
--
1.7.2.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
[RESEND PATCH 3/6] regulator: arizona-micsupp: Add support for WM8280/WM8281
From: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Reviewed-by: Mark Brown broo...@kernel.org
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/regulator/arizona-micsupp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index 2007900..bfe5dac 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -246,6 +246,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
*/
switch (arizona-type) {
case WM5110:
+ case WM8280:
desc = arizona_micsupp_ext;
micsupp-init_data = arizona_micsupp_ext_default;
break;
--
1.7.2.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
[RESEND PATCH 4/6] gpio: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Signed-off-by: Richard Fitzgerald r...@opensource.wolfsonmicro.com
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/gpio/gpio-arizona.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index fe369f5..9665d0a 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -116,6 +116,7 @@ static int arizona_gpio_probe(struct platform_device *pdev)
switch (arizona-type) {
case WM5102:
case WM5110:
+ case WM8280:
case WM8997:
arizona_gpio-gpio_chip.ngpio = 5;
break;
--
1.7.2.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 v3 2/5] Documentation: dt-bindings: add dt binding info for hi6220
On Tue, Feb 10, 2015 at 07:50:24AM +, Zhangfei Gao wrote:
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
.../devicetree/bindings/usb/hi6220-usb.txt | 49
++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/hi6220-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/hi6220-usb.txt
b/Documentation/devicetree/bindings/usb/hi6220-usb.txt
new file mode 100644
index 000..b8278de
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/hi6220-usb.txt
@@ -0,0 +1,49 @@
+Hisilicon hi6220 SoC USB controller
+-
+
+usb controller is inherited from dwc2, refer dwc2.txt
+-
+
+Required properties:
+- compatible: hisilicon,hi6220-usb
+Refer to dwc2.txt for dwc2 usb properties
+
+
+PHY:
+-
+
+Required properties:
+- compatible: hisilicon,hi6220-usb-phy
+- vcc-supply: phandle to the regulator that provides power to the PHY.
+- clocks: phandle and clock specifier of the PHY clock.
+- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral.
+- hisilicon,gpio-vbus: gpio of detecting vbus.
+- hisilicon,gpio-id: gpio of detecting id.
These should be vbus-gpios and id-gpios respectively.
+
+Example:
+
+ peripheral_ctrl: syscon@f703 {
+ compatible = syscon;
+ reg = 0x0 0xf703 0x0 0x1000;
+ };
We should have a real string for this in addition to syscon.
Thanks,
Mark.
--
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/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC
On Fri, Feb 06, 2015 at 03:37:52PM +, Brent Wang wrote:
Hello Mark,
2015-02-06 18:44 GMT+08:00 Mark Rutland mark.rutl...@arm.com:
On Fri, Feb 06, 2015 at 08:42:22AM +, Brent Wang wrote:
Hello Mark,
2015-02-06 3:30 GMT+08:00 Mark Rutland mark.rutl...@arm.com:
On Thu, Feb 05, 2015 at 09:24:37AM +, Bintian Wang wrote:
Add initial dtsi file to support Hisilicon Hi6220 SoC with
support of Octal core CPUs in two clusters and each cluster
has quard Cortex-A53.
We now use the spin-table method for SMP, and it will be
changed to PSCI later.
If that's the case, please don't place the enable-method and related
properties in this file. Get your bootloader to add the appropriate
properties for its boot protocol.
When is PSCI likely to appear?
PSCI is under development.
Sure. Do you have an estimate as to when it will appear?
Another team will do the job, I can not give my estimation now.
Ok.
What are you using for your PSCI implementation? The ARM Trusted
Firmware?
Yes, ATF.
How are you testing it?
I think cpu hotplug can test it.
Are we certain of the split between components the PSCI implementation
must touch and those the kernel must touch?
Also add dts file to support HiKey development board which
based on Hi6220 SoC and document the devicetree bindings.
These dts files will be changed later and more nodes will be
added to describe other devices.
How is this going to be changed other than the addition of nodes?
Will this DTB continue to work in future? Or do you intend to make
changes that will break support?
My original idea is: use spin-table for SMP now, when firmware is OK to
support PSCI, we submit another patch to replace the spin-table with PSCI.
For any users who have not updated their FW, this will break booting.
This is why I suggest having hte bootloader/FW fill this in as it should
know what enable-method the FW supports.
If DTB should continue to work in the future, we really need to remove
the spin-table
from current dts file, how about just enable one core now?
Which one do you favor or any other suggestion?
If spin-table is just for testing while you await PSCI, drop spin-table
from the dts for now.
So, just booting one core may be the right choice now, right?
Without an enable-method for secondary CPUs, that will be all that's
possible. If your FW/bootlaoder injects the appropriate enable-method,
then you could gain spin-table based SMP bringup while awaiting PSCI,
without there being a DTB compatibility issue.
[...]
+ pm_ctrl: pm_ctrl {
+ compatible = hisilicon,pmctrl, syscon;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x0 0xf7032000 0x0 0x1000;
+ ranges = 0 0x0 0xf7032000 0x1000;
+
+ clock_power: clock3@0 {
+ compatible =
hisilicon,hi6220-clock-power;
+ reg = 0 0x1000;
+ #clock-cells = 1;
+ };
+ };
I really doesn't see the point in having a sub-device that covers the
entirely of the register space of the containing node, and that being
the case I am extremely concerned that the containers are marked as
syscon compatible.
The SoC clocks are designed and placed under different system controllers,
so I define corresponding nodes under different controllers for clock
operation.
What I'm concerned wit hhere is that the pm_ctrl node and the clock3@0
sub-node have the _exact_ same register space.
Given this should mean that the clock3@0 node owns that register space,
having the container node export this as syscon does not make sense. And
the split between pm_ctrl and clock3@) doesn't seem to make sense given
they cover the same space.
I understand your worry and will find the max offset of those clocks
under this controller.
As I asked before, why is pm_ctrl marked as a syscon, and what's the
point of the separate sub-node?
There is no big difference between pm_ctrl and other controller, they
are all designed as
the base address to control some functions of other modules (certainly
include some clock gates).
Are they just different instances of the same IP block, or are there
fundamental differences between them?
Maybe only one node is enough, not one node plus one sub-node ?
At least in the case above, I cannot see a reason to have more than a
single node without a child.
Thanks,
Mark.
--
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] ARM: shmobile: r8a73a4: Move pfc node to work around probe ordering bug
Hi Geert, On Tuesday 10 February 2015 11:19:39 Geert Uytterhoeven wrote: On Mon, Feb 9, 2015 at 7:29 PM, Tony Lindgren t...@atomide.com wrote: * Geert Uytterhoeven ge...@linux-m68k.org [150209 09:17]: On Mon, Feb 9, 2015 at 5:24 PM, Tony Lindgren t...@atomide.com wrote: * Geert Uytterhoeven geert+rene...@glider.be [150206 12:26]: Notes: - It seems several people tried to solve this in the core OF probing code before, but the final solution never went in? - This can be reproduced on other SoCs (e.g. sh73a0 and r8a7740) by moving their pfc nodes before their interrupt controller nodes. - This patch is against my working tree, so it doesn't apply to Simon's repository, but you get the idea No issues with the patch, but here are few comments on the core reasons (without looking at the code in this case) that might help fix similar issues. In all the cases I've seen these errors are caused by non-standard custom initcall levels for drivers like i2c bus. The real solution is to initialize drivers later with standard module_init, and stop the race to the bottom with custom initcall levels. If there is legacy board specific platofrm init code that needs i2c gpios early, that code can probably be moved to initialize later on. In this case no i2c is involved. The drivers for both pinctrl (renesas,pfc-r8a73a4) and irqchip (renesas,irqc) are registered at the same level: - postcore_initcall(sh_pfc_init); - postcore_initcall(irqc_init); Hence the system uses the natural order from within the DTS, and decided to instantiate the pfc before the irqchip. OK I tried converting the renesas,irqc driver to IRQCHIP_DECLARE(). This solves the probe ordering problem, but it no longer allows the use of a platform device. One (quite hackish) possible way around this is to register the platform driver (using a static variable to ensure the driver isn't registered multiple times) in the IRQCHIP_DECLARE'd init function, and then call of_platform_device_create() to create the platform device. This should get the device probed immediately. As I was already adding clock and runtime PM support (which use platform devices), IRQCHIP_DECLARE doesn't look like the right road to follow... -- Regards, Laurent Pinchart -- 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 1/4] dt-bindings: mfd: add lubbock-cplds binding
Robert Jarzmik robert.jarz...@free.fr writes: Add a binding for lubbock motherboard IO board. Signed-off-by: Robert Jarzmik robert.jarz...@free.fr --- Since v3: name change to lubbock-cplds, Lee's comments taken into account. Hi Lee, I hope I have handled all the comments. Is this v4 good for you for mfd tree staging ? Cheers. -- Robert -- 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/6] GSBI CRCI Autoconfiguration Support
On Tue, Feb 10, 2015 at 11:57:27AM -0600, Kumar Gala wrote: On Feb 9, 2015, at 4:01 PM, Andy Gross agr...@codeaurora.org wrote: This patch set adds support for automatic configuration of GSBI DMA CRCI values. DMA operations require that the ADM CRCI mux values be properly configured in the TCSR (Top Control and Status Register) block. During probing of a GSBI device, the client mode must be declared and this can be used to lookup the correct TCSR ADM CRCI MUX settings and then program them so that they are correct before any clients are populated. These patches add the TCSR as a syscon device and that allows the GSBI to access and manipulate the ADM CRCI MUX registers to correctly configure the values based on the GSBI port configuration. Changes since v2: - Use cell-index instead of alias to denote GSBI instance Changes since v1: - Fixed various review comments Andy Gross (6): soc: qcom: gsbi: Add support for ADM CRCI muxing mfd: qcom,tcsr: Add device tree binding for TCSR ARM: DT: apq8064: Add TCSR support ARM: DT: ipq8064: Add TCSR support ARM: DT: msm8660: Add TCSR support ARM: DT: msm8960: Add TCSR support .../devicetree/bindings/mfd/qcom,tcsr.txt | 22 +++ .../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 14 +- arch/arm/boot/dts/qcom-apq8064.dtsi| 14 ++ arch/arm/boot/dts/qcom-ipq8064.dtsi| 14 ++ arch/arm/boot/dts/qcom-msm8660.dtsi|8 ++ arch/arm/boot/dts/qcom-msm8960.dtsi|8 ++ drivers/soc/qcom/Kconfig |1 + drivers/soc/qcom/qcom_gsbi.c | 152 8 files changed, 232 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mfd/qcom,tcsr.txt Series looks good, do we need a qcom_defconfig update to enable anything new for this? - k I'll send a followup to enable qcom_defconfig. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] i8042: intel-8042 DT documentation
В Tue, 3 Feb 2015 11:32:02 -0800
Dmitry Torokhov dmitry.torok...@gmail.com пишет:
On Tue, Feb 03, 2015 at 11:38:16AM +, Mark Rutland wrote:
On Mon, Feb 02, 2015 at 09:48:46PM +, Roman Volkov wrote:
Documentation for 'intel,8042' DT compatible node.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
Signed-off-by: Roman Volkov v1...@v1ros.org
---
.../devicetree/bindings/input/intel-8042.txt | 29
++ 1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/intel-8042.txt
diff --git
a/Documentation/devicetree/bindings/input/intel-8042.txt
b/Documentation/devicetree/bindings/input/intel-8042.txt new file
mode 100644 index 000..2aea7ec --- /dev/null
+++ b/Documentation/devicetree/bindings/input/intel-8042.txt
@@ -0,0 +1,29 @@
+* Intel 8042 Keyboard Controller
+
+Required properties:
+- compatible: should be intel,8042
+- regs: memory for keyboard controller
+- interrupts: two interrupts should be specified (keyboard and
aux)
Is it possible only one of these is wired up?
Yes, and we should support this case. The core of i8042 does.
Do we need to just read these IRQ numbers and leave them negative if
absent? Will it be acceptable? This would look like:
i8042_kbd_irq = platform_get_irq_byname(pdev, kbd);
Testing shows it prints Invalid argument error -22 when an IRQ is
absent and we are not using nokbd/noaux module options.
It might be worth using interrupt-names.
+- command-reg: offset in memory for command register
+- status-reg: offset in memory for status register
+- data-reg: offset in memory for data register
+
+Optional properties:
+- init-reset: Controller should be reset on init and cleanup
Why is this necessary? Can't we just always reset it?
We do not reset by default on x86 because BIOS takes care of this for
us and quite often firmware that emulates i8042 gets confused if we
try to reset it too. Non non-x86 we reset by default. I think we
should do the same for OF case (reset) and not use this property.
+
+Optional Linux-specific properties:
+- linux,kbd_phys_desc: defaults to i8042/serio0
+- linux,aux_phys_desc: defaults to i8042/serio1
+- linux,mux_phys_desc: defaults to i8042/serio%d
As a general note, s/_/-/ in property names please.
That said, I don't follow why we should have these at all. I don't
understand what the description is intended to mean.
In general we want to avoid Linux-specific properties. If a DTB
needs to know about the inernals of an OS it's likely to be fragile
and broken over time.
Right, the desc were carried over from older days to keep dmesg
familiar. With OF it is new platforms so just settle on a generic
description and use it instead of allowing to specify through DT.
+
+
+Example:
+ keyboard@d8008800 {
+ compatible = intel,8042;
+ reg = 0xd8008800 0x100;
+ interrupts = 23 4;
If this is intended to be two interrupts, please bracket them
individually, e.g.
interrupts = 23, 4;
+ command-reg = 0x04;
+ status-reg = 0x04;
Same address?
+ data-reg = 0x00;
+ mux-ports = 2;
This wasn't documented above.
I think active MUX is purely x86 concept, I have never heard of it
being used anywhere else.
Thanks.
--
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 v8 2/4] pinctrl: cygnus: add gpio/pinconf driver
On 2/9/2015 11:20 AM, Dmitry Torokhov wrote:
Hi Ray,
On Wed, Feb 04, 2015 at 09:21:01AM -0800, Ray Jui wrote:
+static int cygnus_gpio_pinmux_add_range(struct cygnus_gpio *chip)
+{
+struct device_node *node = chip-dev-of_node;
+struct device_node *pinmux_node;
+struct platform_device *pinmux_pdev;
+struct gpio_chip *gc = chip-gc;
+int i, ret;
+
+/* parse DT to find the phandle to the pinmux controller */
+pinmux_node = of_parse_phandle(node, pinmux, 0);
+if (!pinmux_node)
+return -ENODEV;
+
+pinmux_pdev = of_find_device_by_node(pinmux_node);
+if (!pinmux_pdev) {
+dev_err(chip-dev, failed to get pinmux device\n);
+return -EINVAL;
+}
+
+/* now need to create the mapping between local GPIO and PINMUX pins */
+for (i = 0; i ARRAY_SIZE(cygnus_gpio_pintable); i++) {
+ret = gpiochip_add_pin_range(gc, dev_name(pinmux_pdev-dev),
+ cygnus_gpio_pintable[i].offset,
+ cygnus_gpio_pintable[i].pin_base,
+ cygnus_gpio_pintable[i].num_pins);
+if (ret) {
+dev_err(chip-dev, unable to add GPIO pin range\n);
+goto err_put_device;
+}
+}
+
+chip-pinmux_is_supported = true;
+
+/* no need for pinmux_pdev device reference anymore */
+put_device(pinmux_pdev-dev);
Sorry I did not notice it before, but of_parse_phandle() takes reference
to the returned device node, so you need to put it here and in error
path as well. Actually you can do:
int ret = 0;
pinmux_node = of_parse_phandle(node, pinmux, 0);
if (!pinmux_node)
return -ENODEV;
pinmux_pdev = of_find_device_by_node(pinmux_node);
/* We do not longer need pinmux node */
of_node_put(pinmux_node);
if (!pinmux_dev)
for (..) {
...
if (ret) {
dev_err(...);
break;
}
}
chip-pinmux_is_supported = (ret == 0);
put_device(..);
return ret;
}
This way you free resources in the same path.
Thanks. I'll make the change.
...
+
+static struct platform_driver cygnus_gpio_driver = {
+.driver = {
+.name = cygnus-gpio,
+.of_match_table = cygnus_gpio_of_match,
+.suppress_bind_attrs = true,
+},
+.probe = cygnus_gpio_probe,
+};
+
+static int __init cygnus_gpio_init(void)
+{
+return platform_driver_probe(cygnus_gpio_driver, cygnus_gpio_probe);
When I asked you to add .suppress_bind_attrs = true I missed the fact
that you were using platform_driver_probe() which already does this
internally. However platform_driver_probe() can't handle deferred
probing, which may or may not be OK. Is there a chance that any of the
resources needed by the driver return -EPROBE_DEFER? If not then it is
safe to continue using platform_driver_probe() and you can drop
suppress_bind_attrs assignment, otherwise it may be better to switch to
platform_driver_register().
Thanks.
No I do not expect any resource that this driver depends on to return
-EPROBE_DEFER. The IOMUX driver that this driver depends on should be
initialized before this driver.
I'll drop .suppress_bind_attrs then. Thanks.
Ray
--
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 v7 0/4] st33zp24 new architecture proposal and st33zp24 spi driver
Hi Christophe, Any news on this patchset ? Unfortunately not - I'm still lacking behind due to a big cold I caught. I'll add it once I pushed the fixes for 3.20 out. (still waiting on vicky's fixed patchset) Peter -- 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 v7 0/4] st33zp24 new architecture proposal and st33zp24 spi driver
Hi Peter, Any news on this patchset ? Best Regards Christophe Le 01/02/2015 22:36, Christophe Ricard a écrit : Hi, The following patchset: - propose a new architecture allowing to share a core st33zp24 data management layer with different phy (i2c spi). For st33zp24 both phy have a proprietary transport protocol. Both are relying on the TCG TIS protocol. At the end, it simplifies the maintenance. - Add an spi phy allowing to support st33zp24 using with an SPI bus. The complete solution got tested in polling and interrupt mode successfully with i2c spi phy. This patchset applies on top of Peter's tree https://github.com/PeterHuewe/linux-tpmdd.git for-james branch on top of: d4989d9f693b9502f9288da5db279c2f8c2e50be tpm/tpm_tis: Add missing ifdef CONFIG_ACPI for pnp_acpi_device I confirm also Jarkko Sakkinen's changes are working with this product with both phy's. - v2 takes into account feedbacks from Jason Gunthorpe. - v3 is reduced to 4 patches as 6 out of 10 got accepted for 3.20. Also compare to v2: * Fix build issue with patch v2 04/10 Replace access to io_lpcpd from struct st33zp24_platform_data to tpm_stm_dev * Fix link issue with patch v2 08/10 Split tpm_i2c_tpm_st33 in 2 layers (core + phy) when building as a module. The symbols wasn't exported in st33zp24.c. * Add missing MODULE_LICENSE in patch v2 09/10 Add st33zp24 spi phy * Fix node example in dts spi documentation in patch v2 10/10 Add dts documentation for st33zp24 spi phy * Fix typo on Jason Gunthorpe first name. Sorry for that :(... * Change contact email address as tpmsupp...@st.com is no more valid - v4 adds missing module_license in st33zp24 - v5 includes as best as possible PeterHuewe comments. - v6 is more explicit about the spi buffer size and remove their buffer (tx_buf/rx_buf) dynamic allocation - v7 fix scripts/checkpatch.pl error Best Regards Christophe Christophe Ricard (4): tpm/tpm_i2c_stm_st33: Replace access to io_lpcpd from struct st33zp24_platform_data to tpm_stm_dev tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy) tpm/st33zp24/spi: Add st33zp24 spi phy tpm/st33zp24/dts/st33zp24-spi: Add dts documentation for st33zp24 spi phy .../bindings/security/tpm/st33zp24-spi.txt | 34 + drivers/char/tpm/Kconfig | 11 +- drivers/char/tpm/Makefile | 2 +- drivers/char/tpm/st33zp24/Kconfig | 30 + drivers/char/tpm/st33zp24/Makefile | 12 + drivers/char/tpm/st33zp24/i2c.c| 276 +++ drivers/char/tpm/st33zp24/spi.c| 392 + drivers/char/tpm/st33zp24/st33zp24.c | 688 drivers/char/tpm/st33zp24/st33zp24.h | 37 + drivers/char/tpm/tpm_i2c_stm_st33.c| 911 - include/linux/platform_data/st33zp24.h | 28 + include/linux/platform_data/tpm_stm_st33.h | 39 - 12 files changed, 1499 insertions(+), 961 deletions(-) create mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt create mode 100644 drivers/char/tpm/st33zp24/Kconfig create mode 100644 drivers/char/tpm/st33zp24/Makefile create mode 100644 drivers/char/tpm/st33zp24/i2c.c create mode 100644 drivers/char/tpm/st33zp24/spi.c create mode 100644 drivers/char/tpm/st33zp24/st33zp24.c create mode 100644 drivers/char/tpm/st33zp24/st33zp24.h delete mode 100644 drivers/char/tpm/tpm_i2c_stm_st33.c create mode 100644 include/linux/platform_data/st33zp24.h delete mode 100644 include/linux/platform_data/tpm_stm_st33.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 0/6] GSBI CRCI Autoconfiguration Support
snip Series looks good, do we need a qcom_defconfig update to enable anything new for this? - k I'll send a followup to enable qcom_defconfig. Correction: Since I use a 'selects MFD_SYSCON' in the Kconfig we shouldn't need anything. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: i2c: add support for omnivision's ov2659 sensor
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote on Thu [2015-Feb-05
16:52:22 +0200]:
Hi Prabhakar,
(CC'ing Benoit Parrot)
On Thursday 05 February 2015 11:55:28 Lad, Prabhakar wrote:
On Thu, Feb 5, 2015 at 11:53 AM, Laurent Pinchart wrote:
On Wednesday 04 February 2015 20:55:02 Lad, Prabhakar wrote:
On Wed, Feb 4, 2015 at 5:03 PM, Laurent Pinchart wrote:
On Thursday 15 January 2015 23:39:23 Lad, Prabhakar wrote:
From: Benoit Parrot bpar...@ti.com
this patch adds support for omnivision's ov2659
sensor.
Signed-off-by: Benoit Parrot bpar...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
.../devicetree/bindings/media/i2c/ov2659.txt | 33 +
.../devicetree/bindings/vendor-prefixes.txt|1 +
MAINTAINERS| 10 +
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/ov2659.c | 1623 +++
include/media/ov2659.h | 33 +
7 files changed, 1712 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/ov2659.txt
create mode 100644 drivers/media/i2c/ov2659.c
create mode 100644 include/media/ov2659.h
[snip]
diff --git a/drivers/media/i2c/ov2659.c b/drivers/media/i2c/ov2659.c
new file mode 100644
index 000..ce8ec8d
--- /dev/null
+++ b/drivers/media/i2c/ov2659.c
@@ -0,0 +1,1623 @@
[snip]
+static const struct ov2659_framesize ov2659_framesizes[] = {
+ { /* QVGA */
+ .width = 320,
+ .height = 240,
+ .regs = ov2659_qvga,
+ .max_exp_lines = 248,
+ }, { /* VGA */
+ .width = 640,
+ .height = 480,
+ .regs = ov2659_vga,
+ .max_exp_lines = 498,
+ }, { /* SVGA */
+ .width = 800,
+ .height = 600,
+ .regs = ov2659_svga,
+ .max_exp_lines = 498,
+ }, { /* XGA */
+ .width = 1024,
+ .height = 768,
+ .regs = ov2659_xga,
+ .max_exp_lines = 498,
+ }, { /* 720P */
+ .width = 1280,
+ .height = 720,
+ .regs = ov2659_720p,
+ .max_exp_lines = 498,
+ }, { /* SXGA */
+ .width = 1280,
+ .height = 1024,
+ .regs = ov2659_sxga,
+ .max_exp_lines = 1048,
+ }, { /* UXGA */
+ .width = 1600,
+ .height = 1200,
+ .regs = ov2659_uxga,
+ .max_exp_lines = 498,
+ },
+};
That's what bothers me the most about drivers for Omnivision sensors.
For some reason (I'd bet on lack of proper documentation) they list a
couple of supported resolutions with corresponding register values,
instead of computing the register values from the format configured by
userspace. That's not the way we want to go. Prabhakar, do you have
enough documentation to fix that ?
I am afraid I have limited documentation here.
How limited ? :-) I assume someone has documentation, given that the patch
contains a larger number of #define's with register names.
Yea I don’t have NDA signed with TI/Omnivision :( because I which I
lack the documentation.
And a quick online search doesn't show any leaked datasheet. Wikileaks isn't
doing a good job ;-)
Benoit, do you think this is something that can be fixed ?
Laurent,
I did spend several days (many moons ago) to try and derive a generic
way to set the output resolution dynamically. However even though
the data sheet is somewhat useful, the various working example config
from the vendor make use of several un-documented registers which
make this pretty much unfeasible.
I am afraid we are stuck with this method for the time being.
Regards,
Benoit Parrot
--
Regards,
Laurent Pinchart
--
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] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Tue, Feb 10, 2015 at 03:52:01PM +, Boris Brezillon wrote: Hi Mark, On Tue, 10 Feb 2015 15:36:28 + Mark Rutland mark.rutl...@arm.com wrote: Hi Boris, On Thu, Jan 29, 2015 at 10:33:38AM +, Boris Brezillon wrote: Add documentation for the virtual irq demuxer. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- .../bindings/interrupt-controller/dumb-demux.txt | 41 ++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt diff --git a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt new file mode 100644 index 000..b9a7830 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt @@ -0,0 +1,41 @@ +* Virtual Interrupt Demultiplexer + +This virtual demultiplexer simply forward all incoming interrupts to its +enabled/unmasked children. +It is only intended to be used by hardware that do not provide a proper way +to demultiplex a source interrupt, and thus have to wake all their children +up so that they can possibly handle the interrupt (if needed). +This can be seen as an alternative to shared interrupts when at least one +of the interrupt children is a timer (and require the irq to stay enabled +on suspend) while others are not. This will prevent calling irq handlers of +non timer devices while they are suspended. This sounds like a DT-workaround for a Linux implementation problem, and I don't think this the right way to solve your problem. I understand your concern, but why are you answering while I asked for DT maintainers reviews for several days (if not several weeks). Why does this have to be in DT at all? Why can we not fix the core to handle these details? We already discussed that with Rob and Thomas, and hiding such a demuxer chip is not an easy task. I'm open to any suggestion to do that, though I'd like you (I mean DT guys) to provide a working implementation (or at least a viable concept) that would silently demultiplex an irq. I am very much not keen on this binding. Yes, but do you have anything else to propose. We're experiencing this warning for 2 releases now, and this is time to find a solution (even if it's not a perfect one). Thoughts on the patch below? Rather than handling this at the desc level it adds an extra flag to the irqaction which can be set/unset during suspend for those irqs we don't want to handle. That way we don't need to tell the core about the mismatch explicitly in DT (or ACPI/board files/whatever). If we can request/free interrupts during suspend then there's some logic missing, but it shows the basic idea. I didn't have a system to hand with shared mismatched IRQF_NO_SUSPEND interrupts, so I had to fake that up in code for testing. Thanks, Mark. 8 From f390ccbb31f06efee49b4469943c8d85d963bfb5 Mon Sep 17 00:00:00 2001 From: Mark Rutland mark.rutl...@arm.com Date: Tue, 10 Feb 2015 20:14:33 + Subject: [PATCH] genirq: allow mixed IRQF_NO_SUSPEND requests In some cases a physical IRQ line may be shared between devices from which we expect interrupts during suspend (e.g. timers) and those we do not (e.g. anything we cut the power to). Where a driver did not request the interrupt with IRQF_NO_SUSPEND, it's unlikely that it can handle being called during suspend, and it may bring down the system. This patch adds logic to automatically mark the irqactions for these potentially unsafe handlers as disabled during suspend, leaving actions with IRQF_NO_SUSPEND enabled. If an interrupt is raised on a shared line during suspend, only the handlers requested with IRQF_NO_SUSPEND will be called. The handlers requested without IRQF_NO_SUSPEND will be skipped as if they had immediately returned IRQF_NONE. Cc: Boris Brezillon boris.brezil...@free-electrons.com Cc: Jason Cooper ja...@lakedaemon.net Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Peter Zijlstra pet...@infradead.org Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com Cc: Thomas Gleixner t...@linutronix.de Signed-off-by: Mark Rutland mark.rutl...@arm.com --- include/linux/interrupt.h | 4 kernel/irq/handle.c | 13 +++- kernel/irq/pm.c | 50 +++ 3 files changed, 62 insertions(+), 5 deletions(-) diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index d9b05b5..49dcb35 100644 --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -57,6 +57,9 @@ * IRQF_NO_THREAD - Interrupt cannot be threaded * IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device *resume time. + * IRQF_NO_ACTION - This irqaction should not be
[PATCH v2] mtd:spi-nor: Add Altera EPCQ Driver
From: Viet Nga Dao vn...@altera.com
Altera EPCQ Controller is a soft IP which enables access to Altera EPCQ and
EPCS flash chips. This patch adds driver for these devices.
Signed-off-by: VIET NGA DAO vn...@altera.com
---
v2:
- Change to spi_nor structure
- Add lock and unlock functions for spi_nor
- Simplify the altera_epcq_lock function
- Replace reg by compatible in device tree
---
.../devicetree/bindings/mtd/altera_epcq.txt| 45 ++
drivers/mtd/spi-nor/Kconfig| 12 +
drivers/mtd/spi-nor/Makefile |1 +
drivers/mtd/spi-nor/altera_epcq.c | 507
drivers/mtd/spi-nor/altera_epcq.h | 116 +
drivers/mtd/spi-nor/spi-nor.c | 86 -
include/linux/mtd/spi-nor.h|3 +-
7 files changed, 764 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
create mode 100644 drivers/mtd/spi-nor/altera_epcq.c
create mode 100644 drivers/mtd/spi-nor/altera_epcq.h
diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt
b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
new file mode 100644
index 000..b6b5e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
@@ -0,0 +1,45 @@
+* MTD Altera EPCQ driver
+
+Required properties:
+- compatible: Should be altr,epcq-1.0
+- reg: Address and length of the register set for the device. It contains
+ the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+ csr_base: Should contain the register configuration base address
+ data_base: Should contain the data base address
+- is-epcs: boolean type.
+If present, the device contains EPCS flashes.
+Otherwise, it contains EPCQ flashes.
+- #address-cells: Must be 1.
+- #size-cells: Must be 0.
+- flash device tree subnode, there must be a node with the following fields:
+- compatible: Should contain the flash name
+- #address-cells: please refer to /mtd/partition.txt
+- #size-cells: please refer to /mtd/partition.txt
+For partitions inside each flash, please refer to /mtd/partition.txt
+
+Example:
+
+epcq_controller_0: epcq@0x0 {
+compatible = altr,epcq-1.0;
+reg = 0x0001 0x 0x0020,
+0x 0x 0x0200;
+reg-names = csr_base, data_base;
+#address-cells = 1;
+#size-cells = 0;
+flash0: epcq256@0 {
+compatible = epcq256;
+#address-cells = 1;
+#size-cells = 1;
+partition@0 {
+/* 16 MB for raw data. */
+label = EPCQ Flash 0 raw data;
+reg = 0x0 0x100;
+};
+partition@100 {
+/* 16 MB for jffs2 data. */
+label = EPCQ Flash 0 JFFS 2;
+reg = 0x100 0x100;
+};
+};
+}; //end epcq@0x0 (epcq_controller_0)
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 64a4f0e..83178b9 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -28,4 +28,16 @@ config SPI_FSL_QUADSPI
This enables support for the Quad SPI controller in master mode.
We only connect the NOR to this controller now.
+config SPI_ALTERA_EPCQ
+tristate Support Altera EPCQ/EPCS Flash chips
+depends on OF
+help
+ This enables access to Altera EPCQ/EPCS flash chips, used for data
+ storage. See the driver source for the current list,
+ or to add other chips.
+
+ If you want to compile this driver as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want),
+ say M here and read file:Documentation/kbuild/modules.txt.
+
endif # MTD_SPI_NOR
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 6a7ce14..ff9437b 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_MTD_SPI_NOR)+= spi-nor.o
obj-$(CONFIG_SPI_FSL_QUADSPI)+= fsl-quadspi.o
+obj-$(CONFIG_SPI_ALTERA_EPCQ)+= altera_epcq.o
diff --git a/drivers/mtd/spi-nor/altera_epcq.c
b/drivers/mtd/spi-nor/altera_epcq.c
new file mode 100644
index 000..9db0d05
--- /dev/null
+++ b/drivers/mtd/spi-nor/altera_epcq.c
@@ -0,0 +1,507 @@
+/*
+ * Copyright (C) 2014 Altera Corporation. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
Re: [PATCH RFC v8 11/21] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver
Hi Philipp, On Fri, Feb 06, 2015 at 04:13:20PM +0800, Liu Ying wrote: On Thu, Feb 05, 2015 at 11:10:04AM +0100, Philipp Zabel wrote: Am Mittwoch, den 31.12.2014, 16:23 +0800 schrieb Liu Ying: This patch adds device tree bindings for Synopsys DesignWare MIPI DSI host controller DRM bridge driver. Signed-off-by: Liu Ying ying@freescale.com --- v7-v8: * None. v6-v7: * None. v5-v6: * Add the #address-cells and #size-cells properties in the example 'ports' node. * Remove the useless input-port properties from the example port@0 and port@1 nodes. v4-v5: * None. v3-v4: * Newly introduced in v4. This is separated from the relevant driver patch in v3 to address Stefan Wahren's comment. .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 73 ++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt new file mode 100644 index 000..f88a8d6 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt @@ -0,0 +1,73 @@ +Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller + +The controller is a digital core that implements all protocol functions +defined in the MIPI DSI specification, providing an interface between +the system and the MIPI DPHY, and allowing communication with a MIPI DSI +compliant display. + +Required properties: + - #address-cells: Should be 1. + - #size-cells: Should be 0. + - compatible: The compatible string should be fsl,imx6q-mipi-dsi for + i.MX6q/sdl SoCs. For other SoCs, please refer to their specific + device tree binding documentations. I think the compatible property should additionally contain snps,dw-mipi-dsi. Also I think other SoCs using the same IP core should eventually list their compatibles here, but that's for later. How about: + - compatible: The compatible string contain fsl,imx6q-mipi-dsi for + i.MX6q/sdl SoCs. For other SoCs, please refer to their specific + device tree binding documentations. A common compatible string + snps,dw-mipi-dsi should be appended for all SoCs. I'm not sure if snps,dw-mipi-dsi should be appended. Is it a compatible string that SoC specific drivers should actually use to bind a device? As Andy mentioned in [1], DW MIPI DSI embedded in RK618 is configured via I2C bus, while i.MX6Q/DL is configured via ARM bus... Another concern is that if users only specify snps,dw-mipi-dsi in their device tree sources and use a kernel which supports multiple platforms, say ARM multi v7 platforms, could several enabled SoC specific drivers be probed for a single DW MIPI DSI device? [1] http://lists.freedesktop.org/archives/dri-devel/2014-December/074344.html + - reg: Represent the physical address range of the controller. + - interrupts: Represent the controller's interrupt to the CPU(s). + - clocks, clock-names: Phandles to the controller pll reference and + core configuration clocks, as described in [1]. From the MIPI CSI-2 datasheets it looks like the D-PHY has a refclk and a cfg_clk input. So I suspect from the name of the core_cfg clock, that it actually represents two clock inputs, the cfg_clk wired to the D-PHY and a core clock wired to the MIPI DSI host controller. I am not sure if there are designs that control those clocks separately, but I think it'd be safer to split this into two clocks in the device tree. Our internal MIPI DSI SoC owner gave me some feedbacks on the clock sources. According to him, the Synopsys DesignWare MIPI DSI host controller needs four clock sources from an application platform - pclk, refclk, cfg_clk and dpipclk. These clocks are mentioned in the DesignWare Cores MIPI DSI Host Controller Databook, 1.01a1.30a.pdf documentation. Quote some words from the documentation: pclk- APB clock signal. refclk - D-PHY reference clock used for Master-side serial clock generation in clock multiplying unit(PLL). cfg_clk - D-PHY Configuration clock used for the initialization of the PHY. It is also used for exiting ULPS state. dpipclk - Input Pixel clock signal. The below table reflects how does i.MX6Q/DL provide the pclk, refclk and cfg_clk for the DesignWare MIPI DSI host controller, according to the SoC owner. | Synopsys | i.MX6Q/DL MIPI DSI | | DesignWare|| | documentation |clock | clock root | CCM_CCGR bits |
[Patch v3 0/2] Add Qualcomm ADM dmaengine driver
This patch set introduces the dmaengine driver for the Qualcomm Application Data Mover (ADM) DMA controller present on MSM8x60, APQ8064, and IPQ8064 devices. The initial version of this driver will only support slave DMA operations between system memory and peripherals. Flow control via the CRCI (client rate control interface) is supported and can be configured via device tree configuration. Flow control usage is required for some peripheral devices. Changes from v2: - Removed extraneous achan variable from xlate function - Reworked crci check in slave_sg function - Added mux field to async_desc structure. - Reworked dma start function to use crci and mux values directly from structure. - Added disable of clocks in probe error paths. - Changed to use #define for fixed number of channels. Changes since v1: - Fixed various review comments - Fixed some descriptor programming issues. - Added single descriptors to support sub burst length transactions. Selection of single or box descriptors depends on the sg length and burst size. - Removed use of crci in the dmas property. CRCI is now designated via the slave_config structure and will be stored in slave_id. Andy Gross (2): dt/bindings: qcom_adm: Fix channel specifiers dmaengine: Add ADM driver Documentation/devicetree/bindings/dma/qcom_adm.txt | 16 +- drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/qcom_adm.c | 902 4 files changed, 919 insertions(+), 10 deletions(-) create mode 100644 drivers/dma/qcom_adm.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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: [systemd-devel] Making udev emit a signal when it is done loading modules
On Wed, Jan 28, 2015 at 02:38:52AM +0100, Lennart Poettering wrote: To clarify this: if people do this, then this pulls in systemd-udev-settle.service, which slows down boot. Every service that does that is hence a majour source of slowness. It's a hack to use this, not a solution. Well, yes. There aren't really any good solutions with our event driven model - we never finish booting, we just get to a point where nothing has been happening for a while. I have been thinking that we need to just admit that properly and do something timer based - have a timer that gets reset every time we instantiate something, then do all our end of boot actions when nothing happened for a while. It's not elegant but I don't think elegant is a realistic goal here. signature.asc Description: Digital signature
[Patch v3 1/2] dt/bindings: qcom_adm: Fix channel specifiers
This patch removes the crci information from the dma channel property. At least one client device requires using more than one CRCI value for a channel. This does not match the current binding and the crci information needs to be removed. Instead, the client device will provide this information via other means. Signed-off-by: Andy Gross agr...@codeaurora.org --- Documentation/devicetree/bindings/dma/qcom_adm.txt | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/qcom_adm.txt b/Documentation/devicetree/bindings/dma/qcom_adm.txt index 9bcab91..38d45f8 100644 --- a/Documentation/devicetree/bindings/dma/qcom_adm.txt +++ b/Documentation/devicetree/bindings/dma/qcom_adm.txt @@ -4,8 +4,7 @@ Required properties: - compatible: must contain qcom,adm for IPQ/APQ8064 and MSM8960 - reg: Address range for DMA registers - interrupts: Should contain one interrupt shared by all channels -- #dma-cells: must be 2. First cell denotes the channel number. Second cell - denotes CRCI (client rate control interface) flow control assignment. +- #dma-cells: must be 1. First cell denotes the channel number. - clocks: Should contain the core clock and interface clock. - clock-names: Must contain core for the core clock and iface for the interface clock. @@ -22,7 +21,7 @@ Example: compatible = qcom,adm; reg = 0x1830 0x10; interrupts = 0 170 0; - #dma-cells = 2; + #dma-cells = 1; clocks = gcc ADM0_CLK, gcc ADM0_PBUS_CLK; clock-names = core, iface; @@ -35,15 +34,12 @@ Example: qcom,ee = 0; }; -DMA clients must use the format descripted in the dma.txt file, using a three +DMA clients must use the format descripted in the dma.txt file, using a two cell specifier for each channel. -Each dmas request consists of 3 cells: +Each dmas request consists of two cells: 1. phandle pointing to the DMA controller 2. channel number - 3. CRCI assignment, if applicable. If no CRCI flow control is required, use 0. -The CRCI is used for flow control. It identifies the peripheral device that -is the source/destination for the transferred data. Example: @@ -56,7 +52,7 @@ Example: cs-gpios = qcom_pinmux 20 0; - dmas = adm_dma 6 9, - adm_dma 5 10; + dmas = adm_dma 6, + adm_dma 5; dma-names = rx, tx; }; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 2/2] dmaengine: Add ADM driver
Add the DMA engine driver for the QCOM Application Data Mover (ADM) DMA controller found in the MSM8x60 and IPQ/APQ8064 platforms. The ADM supports both memory to memory transactions and memory to/from peripheral device transactions. The controller also provides flow control capabilities for transactions to/from peripheral devices. The initial release of this driver supports slave transfers to/from peripherals and also incorporates CRCI (client rate control interface) flow control. Signed-off-by: Andy Gross agr...@codeaurora.org --- drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/qcom_adm.c | 902 3 files changed, 913 insertions(+) create mode 100644 drivers/dma/qcom_adm.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index f2b2c4e..69bc15e 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -464,4 +464,14 @@ config QCOM_BAM_DMA Enable support for the QCOM BAM DMA controller. This controller provides DMA capabilities for a variety of on-chip devices. +config QCOM_ADM + tristate Qualcomm ADM support + depends on ARCH_QCOM || (COMPILE_TEST OF ARM) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for the Qualcomm ADM DMA controller. This controller + provides DMA capabilities for both general purpose and on-chip + peripheral devices. + endif diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 2022b54..3b7ead6 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -50,3 +50,4 @@ obj-y += xilinx/ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o +obj-$(CONFIG_QCOM_ADM) += qcom_adm.o diff --git a/drivers/dma/qcom_adm.c b/drivers/dma/qcom_adm.c new file mode 100644 index 000..7381c38 --- /dev/null +++ b/drivers/dma/qcom_adm.c @@ -0,0 +1,902 @@ +/* + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only 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 linux/kernel.h +#include linux/io.h +#include linux/init.h +#include linux/slab.h +#include linux/module.h +#include linux/interrupt.h +#include linux/dma-mapping.h +#include linux/scatterlist.h +#include linux/device.h +#include linux/platform_device.h +#include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h +#include linux/of_dma.h +#include linux/reset.h +#include linux/clk.h +#include linux/dmaengine.h + +#include dmaengine.h +#include virt-dma.h + +/* ADM registers - calculated from channel number and security domain */ +#define HI_CH_CMD_PTR(chan, ee)(4*chan + 0x20800*ee) +#define HI_CH_RSLT(chan, ee) (0x40 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE0(chan, ee) (0x80 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE1(chan, ee) (0xc0 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE2(chan, ee) (0x100 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE3(chan, ee) (0x140 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE4(chan, ee) (0x180 + 4*chan + 0x20800*ee) +#define HI_CH_FLUSH_STATE5(chan, ee) (0x1c0 + 4*chan + 0x20800*ee) +#define HI_CH_STATUS_SD(chan, ee) (0x200 + 4*chan + 0x20800*ee) +#define HI_CH_CONF(chan) (0x240 + 4*chan) +#define HI_CH_RSLT_CONF(chan, ee) (0x300 + 4*chan + 0x20800*ee) +#define HI_SEC_DOMAIN_IRQ_STATUS(ee) (0x380 + 0x20800*ee) +#define HI_CI_CONF(ci) (0x390 + 4*ci) +#define HI_CRCI_CONF0 0x3d0 +#define HI_CRCI_CONF1 0x3d4 +#define HI_GP_CTL 0x3d8 +#define HI_CRCI_CTL(crci, ee) (0x400 + 0x4*crci + 0x20800*ee) + +/* channel status */ +#define CH_STATUS_VALIDBIT(1) + +/* channel result */ +#define CH_RSLT_VALID BIT(31) +#define CH_RSLT_ERRBIT(3) +#define CH_RSLT_FLUSH BIT(2) +#define CH_RSLT_TPDBIT(1) + +/* channel conf */ +#define CH_CONF_MPU_DISABLEBIT(11) +#define CH_CONF_PERM_MPU_CONF BIT(9) +#define CH_CONF_FLUSH_RSLT_EN BIT(8) +#define CH_CONF_FORCE_RSLT_EN BIT(7) +#define CH_CONF_IRQ_EN BIT(6) + +/* channel result conf */ +#define CH_RSLT_CONF_FLUSH_EN BIT(1) +#define CH_RSLT_CONF_IRQ_ENBIT(0) + +/* CRCI CTL */ +#define CRCI_CTL_MUX_SEL BIT(18) +#define CRCI_CTL_RST BIT(17) + +/* CI configuration */ +#define CI_RANGE_END(x)(x 24) +#define CI_RANGE_START(x) (x 16) +#define CI_BURST_4_WORDS 0x4 +#define CI_BURST_8_WORDS
Re: [PATCH v2] ARM: dts: exynos5420: Add maudio power domain
On pon, 2015-02-09 at 14:57 +0100, Krzysztof Kozlowski wrote:
Add maudio power domain to Exynos 5420 DTSI file so its state could be
tracked. This actually won't power down this domain because the pl330
dmaengine driver (for adma channel) uses IRQ safe runtime PM. Thus the
patch should not introduce any functional change except of visibility of
this domain to the system.
I was wrong. There is a functional change during suspend.
The mau domain is powered off after suspending adma device (pl330 dma).
However later clk-exynos-audss receives syscore suspend notification and
tries to save mau clock registers. This results in imprecise abort
because mau power domain is turned off.
I think it is better to drop my patch.
Krzysztof
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes sinve v1:
1. Use generic power domain bindings (suggested by Javier).
2. Add Javier's reviewed-by.
---
arch/arm/boot/dts/exynos5420.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 9dc2e9773b30..28c4a2f4b991 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -288,6 +288,12 @@
pclk1, clk1, pclk2, clk2;
};
+ mau_pd: power-domain@100440E0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440E0 0x20;
+ #power-domain-cells = 0;
+ };
+
pinctrl_0: pinctrl@1340 {
compatible = samsung,exynos5420-pinctrl;
reg = 0x1340 0x1000;
@@ -346,6 +352,7 @@
#dma-cells = 1;
#dma-channels = 6;
#dma-requests = 16;
+ power-domains = mau_pd;
};
pdma0: pdma@121A {
@@ -415,6 +422,7 @@
pinctrl-names = default;
pinctrl-0 = i2s0_bus;
status = disabled;
+ power-domains = mau_pd;
};
i2s1: i2s@12D6 {
--
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] sh-pfc: add R8A7794 PFC support
Hello. On 02/11/2015 01:25 AM, Sergei Shtylyov wrote: From: Hisashi Nakamura hisashi.nakamura...@renesas.com Add PFC support for the R8A7794 SoC including pin groups for some on-chip devices such as ETH, I2C, INTC, MSIOF, QSPI, [H]SCIF... Signed-off-by: Hisashi Nakamura hisashi.nakamura...@renesas.com [Sergei: squashed together several patches, fixed the MLB_CLK typo, added IRQ4.. IRQ9 pin groups, fixed IRQn comments, added ETH B pin group names, removed stray new line and fixed typos in the comments in the pinmux_config_regs[] initializer, added reasonable and removed unreasonable copyrights, modified the bindings document, renamed, added changelog.] Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com Oops, forgot to rebase to the 'linux-pinctrl' repo's 'devel' branch (should I use some other?), and the patch doesn't apply there. Please ignore. WBR, Sergei -- 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 0/3] Add initial DT support for Qualcomm SPMI PMIC devices
On Tue, Feb 03, 2015 at 02:17:57PM +0200, Ivan T. Ivanov wrote: Following set of patches add initial DT support for PMIC devices found on recent Quqalcomm chipsets. Details for SPMI bus and PMIC arbiter could be found here [1]. Looks fine. Reviewed-by: Andy Gross agr...@codeaurora.org -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 4/4] ARM: dts: cygnus: enable GPIO based hook detection
This enables GPIO based phone hook detection for Broadcom BCM911360
phone factor board (bcm911360_entphn)
Signed-off-by: Ray Jui r...@broadcom.com
---
arch/arm/boot/dts/bcm911360_entphn.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts
b/arch/arm/boot/dts/bcm911360_entphn.dts
index d2ee952..7db4843 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -33,6 +33,7 @@
/dts-v1/;
#include bcm-cygnus.dtsi
+#include dt-bindings/input/input.h
/ {
model = Cygnus Enterprise Phone (BCM911360_ENTPHN);
@@ -50,4 +51,16 @@
uart3: serial@18023000 {
status = okay;
};
+
+ gpio_keys {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ hook {
+ label = HOOK;
+ linux,code = KEY_O;
+ gpios = gpio_asiu 48 0;
+ };
+ };
};
--
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 v9 3/4] ARM: dts: enable GPIO for Broadcom Cygnus
This enables all 3 GPIO controllers including the ASIU GPIO, the
chipcommonG GPIO, and the ALWAYS-ON GPIO, for Broadcom Cygnus SoC
Signed-off-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index b014ce5..a3b8621 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -60,6 +60,39 @@
0x0301d24c 0x2c;
};
+ gpio_crmu: gpio@03024800 {
+ compatible = brcm,cygnus-gpio;
+ reg = 0x03024800 0x50,
+ 0x03024008 0x18;
+ ngpios = 6;
+ #gpio-cells = 2;
+ gpio-controller;
+ };
+
+ gpio_ccm: gpio@1800a000 {
+ compatible = brcm,cygnus-gpio;
+ reg = 0x1800a000 0x50,
+ 0x0301d164 0x20;
+ ngpios = 24;
+ #gpio-cells = 2;
+ gpio-controller;
+ interrupts = GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-controller;
+ };
+
+ gpio_asiu: gpio@180a5000 {
+ compatible = brcm,cygnus-gpio;
+ reg = 0x180a5000 0x668;
+ ngpios = 146;
+ #gpio-cells = 2;
+ gpio-controller;
+
+ pinmux = pinctrl;
+
+ interrupt-controller;
+ interrupts = GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH;
+ };
+
amba {
#address-cells = 1;
#size-cells = 1;
--
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] thermal: armada: read stable temp on Armada XP
The current register being used to read the temperature returns a noisy value
that is prone to variance and occasional outliers. The value in the thermal
manager control and status register appears to have the same scale but much
less variability.
Add a marvell,armadaxp-filtered-thermal config which is set up to read from
the Thermal Manager Control and Status Register at 0x184c4 rather than the
Thermal Sensor Status Register at 0x182b0. The only difference is the
temperature value shift. The original marvell,armadaxp-thermal is retained
for device tree compatibility.
This also fixes Armada XP clearing the disable bit in the wrong register. Bit 0
of the sensor register was being cleared but that bit is read-only. The disable
bit doesn't seem to have an effect on the temperature sensor value, however, so
this doesn't make a material difference.
This problem was detected when running with the watchdog(8) daemon polling the
thermal value. In one instance I observed a single read of over 200 degrees C
which caused a spurious watchdog-initiated reboot. I have since observed
individual outliers of ~20 degrees C. With this change and the corresponding
device tree update, the temperature is much more stable.
Signed-off-by: Tyler Hall tylerwh...@gmail.com
---
If there's a better way to handle this than a separate binding, I'm open to
suggestions.
My conclusions about these registers are based on experimental data. The
documentation is very sparse, but the Thermal Manager Control and Status
Register looks like the preferred register given the way it is laid out in the
public spec.
I have the small corresponding patch to the dts which I can submit separately.
Thanks
Tyler
.../devicetree/bindings/thermal/armada-thermal.txt | 8
drivers/thermal/armada_thermal.c| 13 +
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 4698e0e..0d6a3f1 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -7,6 +7,14 @@ Required properties:
marvell,armada375-thermal
marvell,armada380-thermal
marvell,armadaxp-thermal
+ marvell,armadaxp-filtered-thermal
+
+ Note: marvell,armadaxp-filtered-thermal is adjusted to read
+ the hardware-filtered value in the thermal manager
+ control/status register rather than the raw sensor value in the
+ thermal sensor status register. marvell,armadaxp-thermal
+ remains for backward compatibility. The sensor reg address must
+ also point to the appropriate register.
- reg: Device's register space.
Two entries are expected, see the examples below.
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index c2556cf..d3c2ad3 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -196,6 +196,15 @@ static const struct armada_thermal_data armadaxp_data = {
.coef_div = 13825,
};
+static const struct armada_thermal_data armadaxp_filt_data = {
+ .init_sensor = armadaxp_init_sensor,
+ .temp_shift = 1,
+ .temp_mask = 0x1ff,
+ .coef_b = 315300UL,
+ .coef_m = 1000UL,
+ .coef_div = 13825,
+};
+
static const struct armada_thermal_data armada370_data = {
.is_valid = armada_is_valid,
.init_sensor = armada370_init_sensor,
@@ -236,6 +245,10 @@ static const struct of_device_id armada_thermal_id_table[]
= {
.data = armadaxp_data,
},
{
+ .compatible = marvell,armadaxp-filtered-thermal,
+ .data = armadaxp_filt_data,
+ },
+ {
.compatible = marvell,armada370-thermal,
.data = armada370_data,
},
--
2.3.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
