Re: [PATCH 2/2] i2c: designware: Add i2c-designware-hs
Hi zhangfei gao,
On Sun, Jun 09, 2013 at 04:59:48PM +0800, zhangfei gao wrote:
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware-hs.txt
@@ -0,0 +1,30 @@
+* Hisilicon I2C Controller
+
+Required properties :
+
+ - compatible : should be hisilicon,designware-i2c
+ - reg : Offset and length of the register set for the device
+ - interrupts : IRQ where IRQ is the interrupt number.
+
+Example :
+
+ i2c0: i2c@fcb08000 {
+ compatible = hs,designware-i2c;
A few comments on this one:
1. You should Cc devicetree-discuss@lists.ozlabs.org on patches touching ftd
bindings (added to Cc)
2. The convention is to use the IC block designer in the compatible
property
prefix, in this case Symopsys (snps)
3. This does not match the compatible property in hs_dw_i2c_of_match[] below
where you use hisilicon,designware-i2c
4. Please update Documentation/devicetree/bindings/vendor-prefixes.txt when
adding new vendor prefixes
Thanks Baruch for the kind education, really useful.
How about using .compatible = snps,hisilicon-i2c
I don't think this is needed. See below.
+ Client in i2c0 bus with add 0x58 could be added as example
+ i2c0: i2c@fcb08000 {
+ status = ok;
The convention is to use okay.
got it.
+ pinctrl-names = default;
+ pinctrl-0 = i2c0_pmx_func i2c0_cfg_func;
+ i2c_client1: i2c_client@58 {
+ compatible = hisilicon,i2c_client_tpa2028;
+ reg = 0x58;
+ };
+ };
[...]
The code below looks like a direct copy of i2c-designware-platdrv.c. Is
there
any reason you can't use that code instead?
Not understood i2c-designware-platdrv.c can be directly touched.
Usually, there is register function, or external function call.
It would be great if we could directly add hisilicon support in
i2c-designware-platdrv.c.
How about adding these code to distinguish.
The concern is will platdrv.c become bigger and bigger?
The overall code size becomes much bigger when duplicating the code. It makes
code maintenance harder.
What in case private register have to be accessed?
Good question. I don't know what is the common convention in this case. Do you
have such a need here?
struct dw_i2c_data {
u32 accessor_flags;
unsigned int tx_fifo_depth;
unsigned int rx_fifo_depth;
};
static struct dw_i2c_data hisilicon_data = {
.accessor_flags = ACCESS_32BIT,
This should be detected automatically in i2c_dw_init(). When ACCESS_16BIT is
not set, access is 32bit wide. Doesn't it work for you?
.tx_fifo_depth = 16,
.rx_fifo_depth = 16,
These should be encoded in new device-tree properties named tx-fifo-size,
and rx-fifo-size. For example, see
Documentation/devicetree/bindings/powerpc/4xx/emac.txt.
baruch
};
{ .compatible = snps,hisilicon-i2c, .data = hisilicon_data},
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] clk: nomadik: implement the Nomadik clocks properly
The Nomadik clock implementation was a stub just using fixed clocks. This implements the clocks properly instead of relying on them all being on at boot and leaving them all on. The PLLs are on the top locking to the main chrystal oscillator, then the HCLK for the peripherals are below PLL2. The gated clocks are implemented with zero cells and given the clock ID as a property of each node, so every gate need to have its own node in the device tree. This is because the gate registers contain both HCLK gates and PCLK gates, where the latter has HCLK as parent. As can be seen from the register layout, this is a complete mixup, which means all these gates need their own node to properly model parent/child relations for PCLKs apart from the HCLKs. This driver also adds a helpful debugfs file to inspect the hardware state of the clock gates. This is the end result in debugfs/clk/clk_summary after applying a proper device tree: ulpiclk0 06000 mxtal 3 31920 pll21 186400 clk483 34800 rngcclk 1 14800 usbmclk 0 04800 mshcclk 0 04800 mspclk3 0 04800 x3dclk0 04800 skeclk0 04800 owmclk0 04800 mspclk2 0 04800 mspclk1 0 04800 uart2clk 0 04800 ipbmcclk 0 04800 ipi2cclk 0 04800 usbclk0 04800 mspclk0 0 04800 uart1clk 1 24800 i2c1clk 0 04800 i2c0clk 0 04800 sdiclk1 14800 uart0clk 0 04800 sspiclk 0 04800 irdaclk 0 04800 clk720 07200 difclk0 07200 clcdclk 0 07200 clk216 0 021600 hsiclkrx 0 021600 clk1080 010800 hsiclktx 0 010800 clk27 0 02700 pll11 126400 hclk 3 326400 hclkrng 1 126400 hclkusbm 0 026400 hclkcryp 0 026400 hclkhash 0 026400 hclk3d0 026400 hclkhpi 0 026400 hclksva 0 026400 hclksaa 0 026400 hclkdif 0 026400 hclkusb 0 026400 hclkclcd 0 026400 hclkdma1 0 026400 hclksdram 0 026400 hclksmc 1 126400 hclkdma0 0 026400 pclk 7 926400 pclkmsp3 0 026400 pclkmshc 0 026400 pclkhsem 0 026400 pclkske0 026400 pclkowm0 026400 pclkmsp2 0 026400 pclkmsp1 0 026400 pclkuart2 0 026400 pclkxti0 026400 pclkhsi0 026400 pclkmsp0 0 026400 pclkuart1 1 126400 pclki2c1 0 026400 pclki2c0 0 026400 pclksdi1 126400 pclkuart0 1 126400 pclkssp0 026400 pclkirda 0 026400 timclk 1 1240 Signed-off-by: Linus Walleij linus.wall...@linaro.org --- Hi Mike, I'm seeking an ACK to take this into the ARM SoC tree on top of the other pending Nomadik clock patches there. --- .../devicetree/bindings/clock/st,nomadik.txt | 104 drivers/clk/clk-nomadik.c | 553 - 2 files changed, 654 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/st,nomadik.txt diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt new file mode 100644 index 000..7fc0977 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st,nomadik.txt @@ -0,0 +1,104 @@ +ST Microelectronics Nomadik SRC System Reset and Control + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The Nomadik SRC controller is responsible of controlling chrystals, +PLLs and clock gates. + +Required properties for the SRC node: +- compatible: must be stericsson,nomadik-src +- reg: must contain the SRC register base and size + +Optional properties for the
[patch -next] spi: spi-xilinx: cleanup a check in xilinx_spi_txrx_bufs()
'!' has higher precedence than comparisons so the original condition is equivalent to if (xspi-remaining_bytes == 0). This makes the static checkers complain. xspi-remaining_bytes is signed and from looking at the code briefly, I think it might be able to go negative. I suspect that going negative may cause a bug, but I don't have the hardware and can't test. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c index 0b8398c..fb56fcf 100644 --- a/drivers/spi/spi-xilinx.c +++ b/drivers/spi/spi-xilinx.c @@ -301,7 +301,7 @@ static int xilinx_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t) } /* See if there is more data to send */ - if (!xspi-remaining_bytes 0) + if (xspi-remaining_bytes = 0) break; } ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote:
On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote:
Right. I think we have two options here for laying the DT ranges.
1) This is the proposal implied in the patchset I sent:
mbus {
ranges = we only put the internal-reg translation here
devbus-bootcs {
ranges = 0 {target_id/attribute} {window_physical_base} {size}
}
}
As Jason explained, you cannot have the window_physical_base in the child
device, that just wouldn't work. I don't know if that's a typo or a thinko ;-)
I also think {size} above there would just be 0x, right?
2) This is what Jason is proposing in his mail:
mbus {
ranges = {target_id/attribute} 0 {window_physical_base} {size}
devbus-bootcs {
ranges = 0 {target_id/attribute} 0 {size}
}
}
Of course this looks much cleaner, but it forces a lot of duplication
in the DT files. Now, if you see some of the recent patches we've been
sending, I think this duplication is very error-prone, and it'll be a
nightmare to maintain. Let me propose an example to show this
duplication:
I don't see where that duplication comes in. The ranges in the
devbus-bootcs are just describing how the hardware maps the
child address space into the global mbus space, and that never
changes. For the cases that only have a single device underneath,
you can actually put an empty ranges property in there and adapt
the regs property of whatever sits underneath it. These two
representations would do exactly the same for instance:
a)
mbus {
ranges = ...;
devbus-bootcs {
#address-cells = 1;
#size-cells = 1;
ranges = 0 MBUS_BOOTCS 0 0x;
flash {
regs = 0 0x10;
};
};
};
mbus {
ranges = ...;
devbus-bootcs {
#address-cells = 2;
#size-cells = 1;
ranges;
flash {
regs = MBUS_BOOTCS 0 0x10;
};
};
};
Let's suppose we have a board A with its armada-A.dts,
and a common one armada.dtsi.
The common dtsi file would have this ranges property:
/* armada.dtsi */
mbus {
ranges = internal_regs_id 0 internal_regs_base internal_regs_size
bootrom_id 0 bootrom_base bootrom_size
}
The A board has a NOR connected to some devbus, so we need to add it
to the ranges, but also need to duplicate the ones in the common dtsi:
/* armada-A.dts */
mbus {
ranges = internal_regs_id 0 internal_regs_base internal_regs_size
bootrom_id 0 bootrom_base bootrom_size
devbus0_id 0 devbus0_base devbus0_size
}
I think the mbus ranges property is best left only in the
board specific .dts file, since you don't know if all of the
mappings are actually set up to the same value by all boot
loaders. In order to avoid a situation where the mbus ranges
describes a setting that is not actually programmed into the
mbus controller by the boot loader, I would leave that empty
by default and only fill it when the OS actually assigns
a mapping.
Now, if we add something at the common level, and extend the ranges
property in the common armada.dtsi, we also have to go through *each* of
the per-board dts files (for *each* board) adding that entry, because
entries *need* to be duplicated. Otherwise you're effectively
shadowing the entries.
We can't really do that anyway, as that would imply we also change
all the boot loaders that have been deployed. I mentioned earlier that
we could also have the mappings we /want/ described in the DT rather the
ones that are set up, but after the discussion about the 0xd0/0xf1
window for the internal registers I think it's better to keep them
in sync all the time. We can leave out mappings here that are set
up but I'd prefer not to put mappings in there that are actually
incorrect.
When assigning the mappings, it's best to just go through all devices
sitting below the mbus and pick an appropriate address for each
'reg' value that gets put into the mbus hardware and into the ranges
property at the same time. The easiest algorithm would be to do
a 'first fit' starting at the highest address that is not already
occupied. If we need the physical address space to be more compact,
we can also first sort all the resources by size. The simpler approach
wastes at most the size difference between the smallest and the largest
range, and that is probably good enough.
I thought this was actually what you implemented already, but it seems
I was wrong.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: nomadik: add the new clocks to the device tree
On Sunday 09 June 2013, Linus Walleij wrote:
+ /*
+* IP AMBA bus clocks, driving the bus side of the
+* peripheral clocking, clock gates.
+*/
+
+ hclkdma0: hclkdma0@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 0;
+ clocks = hclk;
+ };
+ hclksmc: hclksmc@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 1;
+ clocks = hclk;
+ };
+ hclksdram: hclksdram@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 2;
+ clocks = hclk;
+ };
+ hclkdma1: hclkdma1@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 3;
+ clocks = hclk;
+ };
Sorry if I'm being slow to understand how the clock bindings work, but if
you have 63 identical clocks that only differ in ther clock-id, can't you
just have a single DT node for them instead with #clock-cells=1 to pass the
number from the device using it?
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Sun, Jun 09, 2013 at 03:42:24PM +0200, Arnd Bergmann wrote:
On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote:
On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote:
Right. I think we have two options here for laying the DT ranges.
1) This is the proposal implied in the patchset I sent:
mbus {
ranges = we only put the internal-reg translation here
devbus-bootcs {
ranges = 0 {target_id/attribute} {window_physical_base} {size}
}
}
As Jason explained, you cannot have the window_physical_base in the child
device, that just wouldn't work. I don't know if that's a typo or a thinko ;-)
I'm not sure what you mean by that just wouldn't work. I understand it
may be a crappy DT layout, but it definitely works.
The proposal I've sent in this patchset has been fully tested and works
in A370 and AXP, with NOR, and PCIe devices.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Sat, Jun 08, 2013 at 07:45:06PM -0600, Jason Gunthorpe wrote: On Sat, Jun 08, 2013 at 03:38:52PM -0300, Ezequiel Garcia wrote: [...] There are lots and lots of solutions using the pre-processor, please take a look and find one that you feel works for you... Ok, I will. We can always improve the dtc envorionment (as was done recently by adding the preprocessor), we cannot change 'DT ABI' once it it set. Right. Let me rework this using the preprocessor and send a v2. Thanks for the feedback! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
On Sunday 09 June 2013 11:34:24 Ezequiel Garcia wrote:
On Sun, Jun 09, 2013 at 03:42:24PM +0200, Arnd Bergmann wrote:
On Saturday 08 June 2013 15:38:52 Ezequiel Garcia wrote:
On Fri, Jun 07, 2013 at 02:00:54PM -0600, Jason Gunthorpe wrote:
Right. I think we have two options here for laying the DT ranges.
1) This is the proposal implied in the patchset I sent:
mbus {
ranges = we only put the internal-reg translation here
devbus-bootcs {
ranges = 0 {target_id/attribute} {window_physical_base}
{size}
}
}
As Jason explained, you cannot have the window_physical_base in the child
device, that just wouldn't work. I don't know if that's a typo or a thinko
I'm not sure what you mean by that just wouldn't work. I understand it
may be a crappy DT layout, but it definitely works.
I didn't mean to imply that you hadn't tested it. I guess it works fine
if you put the same window_physical_base address into both the source
and destination side mbus ranges property, but then you have to pass
it three times in total and it gets really messy when you reassign it
to a different physical address.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] ethernet/arc/arc_emac - Add new driver
On Fri, Jun 7, 2013 at 6:07 PM, Alexey Brodkin
alexey.brod...@synopsys.com wrote:
Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
instantiated in some legacy ARC (Synopsys) FPGA Boards such as
ARCAngel4/ML50x.
This is based off of current Linus tree, build tested for x86.
+++ b/drivers/net/ethernet/arc/arc_emac_main.c
@@ -0,0 +1,956 @@
+/*
+ * Copyright (C) 2004, 2007-2010, 2011-2013 Synopsys, Inc. (www.synopsys.com)
2004, 2007-2013 ?
+ * Driver for the ARC EMAC 10100 (Rev 5)
If you are going to upstream this, why do you need revision?
+ * Alexey Brodkin: June 2013
+ * -Upsteaming
It will be obvious from existence of your commit in the git tree.
+ * -Refactoring
+ * = Use device-tree/OF for configuration
+ * = Use libphy for phy management
+ * = Remove non-NAPI code sections
+ * = Remove ARC-specific BD management implementations
+ * = Add ethtool functionality
+ *
+ * Vineet Gupta: June 2011
+ * -Issues when working with 64b cache line size
+ * = BD rings point to aligned location in an internal buffer
+ * = added support for cache coherent BD Ring memory
+ *
+ * Vineet Gupta: May 2010
+ * -Reduced foot-print of the main ISR (handling for error cases moved out
+ * into a separate non-inline function).
+ * -Driver Tx path optimized for small packets (which fit into 1 BD = 2K).
+ * Any specifics for chaining are in a separate block of code.
+ *
+ * Vineet Gupta: Nov 2009
+ * -Unified NAPI and Non-NAPI Code.
+ * -API changes since 2.6.26 for making NAPI independent of netdevice
+ * -Cutting a few checks in main Rx poll routine
+ * -Tweaked NAPI implementation:
+ * In poll mode, Original driver would always start sweeping BD chain
+ * from BD-0 upto poll budget (40). And if it got over-budget it would
+ * drop reminder of packets.
+ * Instead now we remember last BD polled and in next
+ * cycle, we resume from next BD onwards. That way in case of
over-budget
+ * no packet needs to be dropped.
+ *
+ * Vineet Gupta: Nov 2009
+ * -Rewrote the driver register access macros so that multiple accesses
+ * in same function use anchor reg to save the base addr causing
+ * shorter instructions
+ *
+ * Amit Bhor, Sameer Dhavale: 2004
I don't know if it's a good idea to keep changelog inside source file,
we have git commit messages for that. You may move this to the first
commit message if you want to keep history, and in future git will do
the job for you.
+ */
+
+#include linux/etherdevice.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_mdio.h
+#include linux/of_net.h
+#include linux/of_platform.h
+
+#include arc_emac_regs.h
+#include arc_emac_mdio.h
Since you are creating driver under its own folder why to keep the
prefixes in the filenames? I think regs.h and mdio.h would be enough.
+/* Transmission timeout */
+#define TX_TIMEOUT (400*HZ/1000)
(400 * HZ / 1000)
+struct arc_emac_priv {
+ /* Pointers to BD rings - Device side */
What about documenting structure fields in the kerneldoc format on the
top of struct definition?
+ dma_addr_t rxbd_dma_hdl;
+ dma_addr_t txbd_dma_hdl;
Perhaps you may consider to reduce field names somethow. I don't know
why rxbd_dma and txbd_dma is not enough.
+ struct sk_buff *rx_skbuff[RX_BD_NUM];
+ struct sk_buff *tx_skbuff[TX_BD_NUM];
Ditto.
+ void __iomem *reg_base_addr;
Ditto.
For example, base or regs.
+/**
+ * arc_emac_adjust_link - Adjust the PHY link speed/duplex.
+ * @net_dev: Pointer to the net_device structure.
+ *
+ * This function is called to change the speed and duplex setting after
+ * auto negotiation is done by the PHY.
+ */
+static void arc_emac_adjust_link(struct net_device *net_dev)
+{
+ struct arc_emac_priv *priv = netdev_priv(net_dev);
+ struct phy_device *phydev = priv-phy_dev;
+ unsigned int reg, status_change = 0;
+
+ BUG_ON(!priv-phy_dev);
+
+ if (phydev-link (priv-old_speed != phydev-speed)) {
+ /* speed changed */
+ switch (phydev-speed) {
+ case SPEED_10:
+ case SPEED_100:
+ break;
+ default:
+ netdev_warn(net_dev, Speed (%d) is not 10/100?\n,
+ phydev-speed);
+ break;
+ }
+ priv-old_speed = phydev-speed;
+ status_change = 1;
+ }
+
+ if (phydev-link (priv-old_duplex != phydev-duplex)) {
+ /* duplex mode changed */
+ reg = EMAC_REG_GET(priv-reg_base_addr, R_CTRL);
+
+ if (DUPLEX_FULL == phydev-duplex)
+ reg |= ENFL_MASK;
+ else
+ reg =
[RESEND PATCH V3 4/8] mmc: mxcmmc: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com --- drivers/mmc/host/mxcmmc.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c index d503635..f47546f 100644 --- a/drivers/mmc/host/mxcmmc.c +++ b/drivers/mmc/host/mxcmmc.c @@ -1067,7 +1067,9 @@ static int mxcmci_probe(struct platform_device *pdev) goto out_release_mem; } - mmc_of_parse(mmc); + ret = mmc_of_parse(mmc); + if (ret) + goto out_free; mmc-ops = mxcmci_ops; /* For devicetree parsing, the bus width is read from devicetree */ -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 0/8] mmc_of_parse() adaptations, switch mvsdio to mmc_of_parse()
Hi, RESEND V3: - Dropped patches 9 and 10, they are part of linux-next already NB: patch 7 as well, but I did not want to change the numbering V3 changes: - Patch 01/10: Added EPROBE_DEFER case to mmc_of_parse() - Added Acked-By to (unmodified) patches 02 and 03. V2 changes: - Converted mvsdio to use mmc_of_parse() - Adapted DTS files using mvsdio accordingly - Changed mmc_of_parse() to return errors to the caller While adding DT support for the Sheevaplugs by Globalscale Technologies (Kirkwood), it turned out that the DT binding of mvsdio lacked features to properly support the hardware (active high/low of CD and WP pins could not be described in DT). This is standard functionality provided by the mmc_of_parse() helper function. However, mmc_of_parse() may allocate GPIO lines. If the allocation fails, it outputs an error, but does not return an error to its caller. Therefore, a proposal to handle errors in mmc_of_parse() is made. This also allows to handle the EPROBE_DEFER case when GPIO is not loaded yet. The patch set is structured as follows: 1 Adapt mmc_of_parse() to return errors 2-6 Handle errors in current drivers using mmc_of_parse() (compile tested only) 7-8 Convert mvsdio and respective dts files to mmc_of_parse() (tested on kirkwood) Simon Baatz (8): mmc: return mmc_of_parse() errors to caller mmc: sh_mmcif: handle mmc_of_parse() errors during probe mmc: tmio-mmc: handle mmc_of_parse() errors during probe mmc: mxcmmc: handle mmc_of_parse() errors during probe mmc: sdhci-pxav3: handle mmc_of_parse() errors during probe mmc: tegra: handle mmc_of_parse() errors during probe ARM: mvebu: Use standard MMC binding for all users of mvsdio mmc: mvsdio: use standard MMC device-tree binding parser mmc_of_parse() arch/arm/boot/dts/armada-370-db.dts|1 + arch/arm/boot/dts/armada-370-mirabox.dts |1 + arch/arm/boot/dts/armada-370-rd.dts|1 + arch/arm/boot/dts/armada-370-xp.dtsi |4 ++ arch/arm/boot/dts/armada-xp-db.dts |1 + arch/arm/boot/dts/kirkwood-dreamplug.dts |1 + .../arm/boot/dts/kirkwood-guruplug-server-plus.dts |2 + arch/arm/boot/dts/kirkwood-mplcec4.dts |2 +- arch/arm/boot/dts/kirkwood-topkick.dts |1 + arch/arm/boot/dts/kirkwood.dtsi|4 ++ drivers/mmc/core/host.c| 30 ++-- drivers/mmc/host/mvsdio.c | 73 +++- drivers/mmc/host/mxcmmc.c |4 +- drivers/mmc/host/sdhci-pxav3.c |7 +- drivers/mmc/host/sdhci-tegra.c |9 ++- drivers/mmc/host/sh_mmcif.c|7 +- drivers/mmc/host/tmio_mmc_pio.c|4 +- include/linux/mmc/host.h |2 +- 18 files changed, 106 insertions(+), 48 deletions(-) -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 3/8] mmc: tmio-mmc: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/mmc/host/tmio_mmc_pio.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c index f508ecb..f1a9d4a 100644 --- a/drivers/mmc/host/tmio_mmc_pio.c +++ b/drivers/mmc/host/tmio_mmc_pio.c @@ -988,7 +988,9 @@ int tmio_mmc_host_probe(struct tmio_mmc_host **host, if (!mmc) return -ENOMEM; - mmc_of_parse(mmc); + ret = mmc_of_parse(mmc); + if (ret 0) + goto host_free; pdata-dev = pdev-dev; _host = mmc_priv(mmc); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 2/8] mmc: sh_mmcif: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/mmc/host/sh_mmcif.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c index ba76a53..6ded7fb 100644 --- a/drivers/mmc/host/sh_mmcif.c +++ b/drivers/mmc/host/sh_mmcif.c @@ -1369,7 +1369,11 @@ static int sh_mmcif_probe(struct platform_device *pdev) ret = -ENOMEM; goto ealloch; } - mmc_of_parse(mmc); + + ret = mmc_of_parse(mmc); + if (ret 0) + goto eofparse; + host= mmc_priv(mmc); host-mmc = mmc; host-addr = reg; @@ -1464,6 +1468,7 @@ eclkupdate: clk_put(host-hclk); eclkget: pm_runtime_disable(pdev-dev); +eofparse: mmc_free_host(mmc); ealloch: iounmap(reg); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 1/8] mmc: return mmc_of_parse() errors to caller
In addition to just logging errors encountered during DT parsing or
allocating GPIO slots for CD/WP, mmc_of_parse() now returns with an error.
In particular, this is needed if the GPIO allocation may return
EPROBE_DEFER.
Signed-off-by: Simon Baatz gmbno...@gmail.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
---
changes in V3:
- Handle EPROBE_DEFER case
drivers/mmc/core/host.c | 30 +-
include/linux/mmc/host.h |2 +-
2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 2a3593d..89f5849 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -306,7 +306,7 @@ static inline void mmc_host_clk_sysfs_init(struct mmc_host
*host)
* parse the properties and set respective generic mmc-host flags and
* parameters.
*/
-void mmc_of_parse(struct mmc_host *host)
+int mmc_of_parse(struct mmc_host *host)
{
struct device_node *np;
u32 bus_width;
@@ -315,7 +315,7 @@ void mmc_of_parse(struct mmc_host *host)
int len, ret, gpio;
if (!host-parent || !host-parent-of_node)
- return;
+ return 0;
np = host-parent-of_node;
@@ -338,6 +338,7 @@ void mmc_of_parse(struct mmc_host *host)
default:
dev_err(host-parent,
Invalid \bus-width\ value %ud!\n, bus_width);
+ return -EINVAL;
}
/* f_max is obtained from the optional max-frequency property */
@@ -367,18 +368,22 @@ void mmc_of_parse(struct mmc_host *host)
host-caps |= MMC_CAP_NEEDS_POLL;
gpio = of_get_named_gpio_flags(np, cd-gpios, 0, flags);
+ if (gpio == -EPROBE_DEFER)
+ return gpio;
if (gpio_is_valid(gpio)) {
if (!(flags OF_GPIO_ACTIVE_LOW))
gpio_inv_cd = true;
ret = mmc_gpio_request_cd(host, gpio);
- if (ret 0)
+ if (ret 0) {
dev_err(host-parent,
Failed to request CD GPIO #%d: %d!\n,
gpio, ret);
- else
+ return ret;
+ } else {
dev_info(host-parent, Got CD GPIO #%d.\n,
gpio);
+ }
}
if (explicit_inv_cd ^ gpio_inv_cd)
@@ -389,14 +394,23 @@ void mmc_of_parse(struct mmc_host *host)
explicit_inv_wp = of_property_read_bool(np, wp-inverted);
gpio = of_get_named_gpio_flags(np, wp-gpios, 0, flags);
+ if (gpio == -EPROBE_DEFER) {
+ ret = -EPROBE_DEFER;
+ goto out;
+ }
if (gpio_is_valid(gpio)) {
if (!(flags OF_GPIO_ACTIVE_LOW))
gpio_inv_wp = true;
ret = mmc_gpio_request_ro(host, gpio);
- if (ret 0)
+ if (ret 0) {
dev_err(host-parent,
Failed to request WP GPIO: %d!\n, ret);
+ goto out;
+ } else {
+ dev_info(host-parent, Got WP GPIO #%d.\n,
+gpio);
+ }
}
if (explicit_inv_wp ^ gpio_inv_wp)
host-caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
@@ -413,6 +427,12 @@ void mmc_of_parse(struct mmc_host *host)
host-pm_caps |= MMC_PM_KEEP_POWER;
if (of_find_property(np, enable-sdio-wakeup, len))
host-pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+
+ return 0;
+
+out:
+ mmc_gpio_free_cd(host);
+ return ret;
}
EXPORT_SYMBOL(mmc_of_parse);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index e326ae2..c8c4fbc 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -369,7 +369,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *);
int mmc_add_host(struct mmc_host *);
void mmc_remove_host(struct mmc_host *);
void mmc_free_host(struct mmc_host *);
-void mmc_of_parse(struct mmc_host *host);
+int mmc_of_parse(struct mmc_host *host);
static inline void *mmc_priv(struct mmc_host *host)
{
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 5/8] mmc: sdhci-pxav3: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
drivers/mmc/host/sdhci-pxav3.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 1ae358e..67ea388 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -252,7 +252,9 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
match = of_match_device(of_match_ptr(sdhci_pxav3_of_match), pdev-dev);
if (match) {
- mmc_of_parse(host-mmc);
+ ret = mmc_of_parse(host-mmc);
+ if (ret)
+ goto err_of_parse;
sdhci_get_of_property(pdev);
pdata = pxav3_get_mmc_pdata(dev);
} else if (pdata) {
@@ -313,10 +315,11 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
return 0;
+err_of_parse:
+err_cd_req:
err_add_host:
clk_disable_unprepare(clk);
clk_put(clk);
-err_cd_req:
err_clk_get:
sdhci_pltfm_free(pdev);
kfree(pxa);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 7/8] ARM: mvebu: Use standard MMC binding for all users of mvsdio
In order to prepare the switch to the standard MMC device tree parser
for mvsdio, adapt all current uses of mvsdio in the dts files to the
standard format.
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
arch/arm/boot/dts/armada-370-db.dts|1 +
arch/arm/boot/dts/armada-370-mirabox.dts |1 +
arch/arm/boot/dts/armada-370-rd.dts|1 +
arch/arm/boot/dts/armada-370-xp.dtsi |4
arch/arm/boot/dts/armada-xp-db.dts |1 +
arch/arm/boot/dts/kirkwood-dreamplug.dts |1 +
.../arm/boot/dts/kirkwood-guruplug-server-plus.dts |2 ++
arch/arm/boot/dts/kirkwood-mplcec4.dts |2 +-
arch/arm/boot/dts/kirkwood-topkick.dts |1 +
arch/arm/boot/dts/kirkwood.dtsi|4
10 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts
b/arch/arm/boot/dts/armada-370-db.dts
index 2353b1f..beee169 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,6 +74,7 @@
*/
status = disabled;
/* No CD or WP GPIOs */
+ broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 14e36e1..45b1077 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -99,6 +99,7 @@
* No CD or WP GPIOs: SDIO interface used for
* Wifi/Bluetooth chip
*/
+broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts
b/arch/arm/boot/dts/armada-370-rd.dts
index 130f839..89c2110 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -64,6 +64,7 @@
pinctrl-names = default;
status = okay;
/* No CD or WP GPIOs */
+ broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 550eb77..0d73570 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -143,6 +143,10 @@
reg = 0xd4000 0x200;
interrupts = 54;
clocks = gateclk 17;
+ bus-width = 4;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
status = disabled;
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts
b/arch/arm/boot/dts/armada-xp-db.dts
index d6cc8bf..7c22a20 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,6 +97,7 @@
pinctrl-names = default;
status = okay;
/* No CD or WP GPIOs */
+ broken-cd;
};
usb@5 {
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts
b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 289e51d..be16a84 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -79,6 +79,7 @@
pinctrl-names = default;
status = okay;
/* No CD or WP GPIOs */
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
index 44fd97d..484a2a6 100644
--- a/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
+++ b/arch/arm/boot/dts/kirkwood-guruplug-server-plus.dts
@@ -72,6 +72,8 @@
mvsdio@9 {
status = okay;
+ /* No CD or WP GPIOs */
+ broken-cd;
};
};
diff --git a/arch/arm/boot/dts/kirkwood-mplcec4.dts
b/arch/arm/boot/dts/kirkwood-mplcec4.dts
index 7588241..bf3a58c 100644
--- a/arch/arm/boot/dts/kirkwood-mplcec4.dts
+++ b/arch/arm/boot/dts/kirkwood-mplcec4.dts
@@ -136,7 +136,7 @@
pinctrl-0 = pmx_sdio pmx_sdio_cd;
pinctrl-names = default;
status = okay;
- cd-gpios = gpio1 15 0;
+ cd-gpios = gpio1 15 1;
/* No WP GPIO */
};
};
diff --git
[RESEND PATCH V3 6/8] mmc: tegra: handle mmc_of_parse() errors during probe
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
drivers/mmc/host/sdhci-tegra.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index e0dba74..7eb62f8 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -205,7 +205,7 @@ static const struct of_device_id sdhci_tegra_dt_match[] = {
};
MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
-static void sdhci_tegra_parse_dt(struct device *dev)
+static int sdhci_tegra_parse_dt(struct device *dev)
{
struct device_node *np = dev-of_node;
struct sdhci_host *host = dev_get_drvdata(dev);
@@ -213,7 +213,7 @@ static void sdhci_tegra_parse_dt(struct device *dev)
struct sdhci_tegra *tegra_host = pltfm_host-priv;
tegra_host-power_gpio = of_get_named_gpio(np, power-gpios, 0);
- mmc_of_parse(host-mmc);
+ return mmc_of_parse(host-mmc);
}
static int sdhci_tegra_probe(struct platform_device *pdev)
@@ -245,7 +245,9 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
tegra_host-soc_data = soc_data;
pltfm_host-priv = tegra_host;
- sdhci_tegra_parse_dt(pdev-dev);
+ rc = sdhci_tegra_parse_dt(pdev-dev);
+ if (rc)
+ goto err_parse_dt;
if (gpio_is_valid(tegra_host-power_gpio)) {
rc = gpio_request(tegra_host-power_gpio, sdhci_power);
@@ -278,6 +280,7 @@ err_add_host:
err_clk_get:
if (gpio_is_valid(tegra_host-power_gpio))
gpio_free(tegra_host-power_gpio);
+err_parse_dt:
err_power_req:
err_alloc_tegra_host:
sdhci_pltfm_free(pdev);
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RESEND PATCH V3 8/8] mmc: mvsdio: use standard MMC device-tree binding parser mmc_of_parse()
Instead of parsing the DT binding on our own, use the standard parser
mmc_of_parse(), introduced by commit 6c56e7a.
Signed-off-by: Simon Baatz gmbno...@gmail.com
---
drivers/mmc/host/mvsdio.c | 73 +
1 file changed, 40 insertions(+), 33 deletions(-)
diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c
index 8960fc8..edfc481 100644
--- a/drivers/mmc/host/mvsdio.c
+++ b/drivers/mmc/host/mvsdio.c
@@ -35,7 +35,7 @@
#define DRIVER_NAMEmvsdio
-static int maxfreq = MVSD_CLOCKRATE_MAX;
+static int maxfreq;
static int nodma;
struct mvsd_host {
@@ -685,7 +685,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
const struct mbus_dram_target_info *dram;
struct resource *r;
int ret, irq;
- int gpio_card_detect, gpio_write_protect;
struct pinctrl *pinctrl;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -718,6 +717,20 @@ static int __init mvsd_probe(struct platform_device *pdev)
if (!IS_ERR(host-clk))
clk_prepare_enable(host-clk);
+ mmc-ops = mvsd_ops;
+
+ mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+
+ mmc-f_min = DIV_ROUND_UP(host-base_clock, MVSD_BASE_DIV_MAX);
+ mmc-f_max = MVSD_CLOCKRATE_MAX;
+
+ mmc-max_blk_size = 2048;
+ mmc-max_blk_count = 65535;
+
+ mmc-max_segs = 1;
+ mmc-max_seg_size = mmc-max_blk_size * mmc-max_blk_count;
+ mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
+
if (np) {
if (IS_ERR(host-clk)) {
dev_err(pdev-dev, DT platforms must have a clock
associated\n);
@@ -726,35 +739,38 @@ static int __init mvsd_probe(struct platform_device *pdev)
}
host-base_clock = clk_get_rate(host-clk) / 2;
- gpio_card_detect = of_get_named_gpio(np, cd-gpios, 0);
- gpio_write_protect = of_get_named_gpio(np, wp-gpios, 0);
+ ret = mmc_of_parse(mmc);
+ if (ret 0)
+ goto out;
} else {
const struct mvsdio_platform_data *mvsd_data;
+
mvsd_data = pdev-dev.platform_data;
if (!mvsd_data) {
ret = -ENXIO;
goto out;
}
+ mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ |
+ MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
host-base_clock = mvsd_data-clock / 2;
- gpio_card_detect = mvsd_data-gpio_card_detect ? : -EINVAL;
- gpio_write_protect = mvsd_data-gpio_write_protect ? : -EINVAL;
- }
-
- mmc-ops = mvsd_ops;
-
- mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
- mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SDIO_IRQ |
- MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
-
- mmc-f_min = DIV_ROUND_UP(host-base_clock, MVSD_BASE_DIV_MAX);
- mmc-f_max = maxfreq;
+ /* GPIO 0 regarded as invalid for backward compatibility */
+ if (mvsd_data-gpio_card_detect
+ gpio_is_valid(mvsd_data-gpio_card_detect)) {
+ ret = mmc_gpio_request_cd(mmc,
+ mvsd_data-gpio_card_detect);
+ if (ret)
+ goto out;
+ } else {
+ mmc-caps |= MMC_CAP_NEEDS_POLL;
+ }
- mmc-max_blk_size = 2048;
- mmc-max_blk_count = 65535;
+ if (mvsd_data-gpio_write_protect
+ gpio_is_valid(mvsd_data-gpio_write_protect))
+ mmc_gpio_request_ro(mmc, mvsd_data-gpio_write_protect);
+ }
- mmc-max_segs = 1;
- mmc-max_seg_size = mmc-max_blk_size * mmc-max_blk_count;
- mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
+ if (maxfreq)
+ mmc-f_max = maxfreq;
spin_lock_init(host-lock);
@@ -777,15 +793,6 @@ static int __init mvsd_probe(struct platform_device *pdev)
goto out;
}
- if (gpio_is_valid(gpio_card_detect)) {
- ret = mmc_gpio_request_cd(mmc, gpio_card_detect);
- if (ret)
- goto out;
- } else
- mmc-caps |= MMC_CAP_NEEDS_POLL;
-
- mmc_gpio_request_ro(mmc, gpio_write_protect);
-
setup_timer(host-timer, mvsd_timeout_timer, (unsigned long)host);
platform_set_drvdata(pdev, mmc);
ret = mmc_add_host(mmc);
@@ -793,10 +800,10 @@ static int __init mvsd_probe(struct platform_device *pdev)
goto out;
if (!(mmc-caps MMC_CAP_NEEDS_POLL))
- dev_notice(pdev-dev, using GPIO %d for card detection\n,
- gpio_card_detect);
+ dev_notice(pdev-dev, using GPIO for card detection\n);
else
- dev_notice(pdev-dev,
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote: this is all a rather round-about way to say that for those people who heard and are thinking of heeding russell's call to be silent and to ignore me Okay, so you've just misrepresented me in the above comment. I never said anything of the sort. The closest that I've come to a comment like that is asking you to stop wasting people's time. So, given your displayed inability to properly convey what people have said to you in a discussion in your own replies, is there *any* reason that anyone should trust you to communicate their position to any other third party? In some ways, I'm *glad* that you've passed everything on verbatum, because it means that it's (hopefully) free from any misrepresentations such as the above. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] clk: exynos4: Add alias for cpufreq related clocks
On 06/08/2013 05:20 PM, Tomasz Figa wrote:
On Thursday 06 of June 2013 16:52:28 Tushar Behera wrote:
cpufreq driver for EXYNOS4 based SoCs are not platform drivers, hence
we cannot currently pass the clock names through a device tree node.
Instead, we need to make them available through a global alias.
'armclk', 'moutcore', 'mout_mpll' and 'mout_apll' clock aliases are
defined.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/clk/samsung/clk-exynos4.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c index 3c1f888..1e4258a 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -356,8 +356,8 @@ struct samsung_fixed_rate_clock
exynos4210_fixed_rate_clks[] __initdata = {
/* list of mux clocks supported in all exynos4 soc's */
struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
-MUX_F(mout_apll, mout_apll, mout_apll_p, SRC_CPU, 0, 1,
-CLK_SET_RATE_PARENT, 0),
+MUX_FA(mout_apll, mout_apll, mout_apll_p, SRC_CPU, 0, 1,
+CLK_SET_RATE_PARENT, 0, mout_apll),
MUX(none, mout_hdmi, mout_hdmi_p, SRC_TV, 0, 1),
MUX(none, mout_mfc1, sclk_evpll_p, SRC_MFC, 4, 1),
MUX(none, mout_mfc, mout_mfc_p, SRC_MFC, 8, 1),
@@ -385,9 +385,9 @@ struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = { MUX(none, mout_g2d, mout_g2d_p, E4210_SRC_IMAGE, 8,
1),
MUX(none, mout_fimd1, group1_p4210, E4210_SRC_LCD1, 0, 4),
MUX(none, mout_mipi1, group1_p4210, E4210_SRC_LCD1, 12, 4),
-MUX_A(sclk_mpll, sclk_mpll, mout_mpll_p, SRC_CPU, 8, 1,
sclk_mpll),
+MUX_A(sclk_mpll, sclk_mpll, mout_mpll_p, SRC_CPU, 8, 1,
mout_mpll),
This is not fully compliant with patch description. I'm not sure if there
weren't any users of the sclk_mpll alias.
As of now, there are no other users of sclk_mpll other than a debug
print within the same file.
MUX_A(mout_core, mout_core, mout_core_p4210,
-SRC_CPU, 16, 1, mout_core),
+SRC_CPU, 16, 1, moutcore),
IMHO those typo corrections are not part of this patch.
But the older drivers (before migration to CCF) were using the clock
moutcore (not mout_core).
MUX_A(sclk_vpll, sclk_vpll, sclk_vpll_p4210,
SRC_TOP0, 8, 1, sclk_vpll),
MUX(mout_fimc0, mout_fimc0, group1_p4210, SRC_CAM, 0, 4),
@@ -534,7 +534,7 @@ struct samsung_div_clock exynos4_div_clks[]
__initdata = { DIV(none, div_spi_pre2, div_spi2, DIV_PERIL2, 8, 8),
DIV(none, div_audio1, mout_audio1, DIV_PERIL4, 0, 4),
DIV(none, div_audio2, mout_audio2, DIV_PERIL4, 16, 4),
-DIV_A(arm_clk, arm_clk, div_core2, DIV_CPU0, 28, 3,
arm_clk),
+DIV_A(arm_clk, arm_clk, div_core2, DIV_CPU0, 28, 3, armclk),
Same here.
Same as above, armclk is used elsewhere, not arm_clk.
DIV_A(sclk_apll, sclk_apll, mout_apll,
DIV_CPU0, 24, 3, sclk_apll),
DIV_F(none, div_mipi_pre0, div_mipi0, DIV_LCD0, 20, 4,
Basically I don't like the idea of those global aliases, which IMHO should
be completely dropped. Someone might not like it, but I'd go with the
conversion of our cpufreq drivers to platform drivers instead, which could
receive things like clocks and regulators using DT-based lookups.
I agree. Migration of exynos-cpufreq driver as a platform driver is the
best solution. But unless someone picks up that work, cpufreq support
for EXYNOS4 based systems is broken because of the incorrect clock aliases.
This is especially important in case of regulators, which currently have
to be hacked by using vdd_arm as regulator name in device tree.
Agree.
CCing people that might be interested in this topic.
Best regards,
Tomasz
Thanks.
--
Tushar Behera
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: Update vdd_arm regulator
On 06/08/2013 05:22 PM, Tomasz Figa wrote:
Hi Tushar,
On Thursday 06 of June 2013 16:32:52 Tushar Behera wrote:
Cpufreq driver for EXYNOS4210 is not a platform driver, hence it is not
possible to provide the regulator supply name through DT bindings.
Since the cpufreq driver requires the regulator to be named as
'vdd_arm', the related regulator name should be kept same.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/boot/dts/exynos4210-origen.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4210-origen.dts
b/arch/arm/boot/dts/exynos4210-origen.dts index bcf8079..bd5f589 100644
--- a/arch/arm/boot/dts/exynos4210-origen.dts
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -192,7 +192,7 @@
};
buck1_reg: BUCK1 {
-regulator-name = VDD_ARM_1.2V;
+regulator-name = vdd_arm;
Yes, this is the hack I mentioned in my review of
[PATCH 0/2] Clock update for EXYNOS4210-CPUFREQ driver
We can hold this patch till we get to a conclusion for the above
mentioned patch set.
Best regards,
Tomasz
regulator-min-microvolt =
95;
regulator-max-microvolt =
135;
regulator-always-on;
--
Tushar Behera
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
