Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Hi Doug,
On Mon, Jan 14, 2013 at 11:15 AM, Vivek Gautam
gautamvivek1...@gmail.com wrote:
Hi Doug,
On Sat, Jan 12, 2013 at 6:20 AM, Doug Anderson diand...@chromium.org wrote:
Vivek,
On Fri, Jan 11, 2013 at 4:40 AM, Vivek Gautam gautamvivek1...@gmail.com
wrote:
+#define HOST_CTRL0_REFCLKSEL_MASK (0x3)
+#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19)
+#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19)
+#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 19)
+
+#define HOST_CTRL0_FSEL_MASK (0x7 16)
+#define HOST_CTRL0_FSEL(_x)((_x) 16)
+#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7)
+#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5)
+#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4)
+#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3)
+#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2)
+#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1)
+#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0)
Add the shifts to the #defines and remove HOST_CTRL0_FSEL(_x). That
makes it match the older phy more closely.
Wouldn't it hamper the readability when shifts are used ??
I mean if we have something like this -
phyhost |= HOST_CTRL0_FSEL(phyclk)
so, if we are using the shifts then
phyhost |= (HOST_CTRL0_FSEL_CLKSEL_24M HOST_CTRL0_FSEL_SHIFT)
I was actually suggesting modifying the #defines like this:
#define HOST_CTRL0_FSEL_SHIFT 16
#define HOST_CTRL0_FSEL_MASK (0x7 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_50M (0x7 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_24M (0x5 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_20M (0x4 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_12M (0x2 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_10M (0x1 HOST_CTRL0_FSEL_SHIFT)
#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 HOST_CTRL0_FSEL_SHIFT)
...then the code doesn't need to think about shifts, right?
right right, sorry i din't get your point earlier. :-(
this way things will be similar in samsung_usbphy_get_refclk_freq()
across exynos 5 and older SoCs.
Is it fine if we don't use macro for SHIFT, earlier code also doesn't use it.
Can we just do like this ..
#define HOST_CTRL0_FSEL_MASK (0x7 16)
#define HOST_CTRL0_FSEL_CLKSEL_50M(0x7 16)
#define HOST_CTRL0_FSEL_CLKSEL_24M(0x5 16)
#define HOST_CTRL0_FSEL_CLKSEL_20M(0x4 16)
#define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 16)
#define HOST_CTRL0_FSEL_CLKSEL_12M(0x2 16)
#define HOST_CTRL0_FSEL_CLKSEL_10M(0x1 16)
#define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 16)
Actually missed one thing here, this HOST_CTRL0_FSEL_CLKSEL_XX is
being used by
HOST/OTG blocks to prepare reference clock, that's the reason we kept
#define HOST_CTRL0_FSEL(_x) ((_x) 16)
and #define OTG_SYS_FSEL(_x) ((_x) 4)
where (_x) is the reference clock returned from
samsung_usbphy_get_refclk_freq().
So in order to avoid confusion we can change the macro names only and
keep something like
#define HOST_CTRL0_FSEL_MASK (0x7 16)
#define HOST_CTRL0_FSEL(_x) ((_x) 16)
#define FSEL_CLKSEL_50M (0x7)
#define FSEL_CLKSEL_24M (0x5)
#define FSEL_CLKSEL_20M (0x4)
#define FSEL_CLKSEL_19200K (0x3)
#define FSEL_CLKSEL_12M (0x2)
#define FSEL_CLKSEL_10M (0x1)
#define FSEL_CLKSEL_9600K(0x0)
...
#define OTG_SYS_FSEL_MASK (0x7 4)
#define OTG_SYS_FSEL(_x) ((_x) 4)
if (IS_ERR(ref_clk)) {
dev_err(sphy-dev, Failed to get reference clock\n);
return PTR_ERR(ref_clk);
}
- switch (clk_get_rate(ref_clk)) {
- case 12 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_24M;
- break;
- case 48 * MHZ:
- refclk_freq = PHYCLK_CLKSEL_48M;
- break;
- default:
- if (sphy-cpu_type == TYPE_S3C64XX)
- refclk_freq = PHYCLK_CLKSEL_48M;
- else
+ if (sphy-cpu_type == TYPE_EXYNOS5250) {
+ /* set clock frequency for PLL */
+ switch (clk_get_rate(ref_clk)) {
+ case 96 * 10:
nit: change to 9600 * KHZ to match; below too.
sure.
+ refclk_freq |= HOST_CTRL0_FSEL_CLKSEL_9600K;
$(make uImage) is stupid [Was: Re: Early kernel hang with big DTB appended]
Hello, unrelated to the original problem ... On Fri, Jan 04, 2013 at 11:18:56AM +0100, Tomasz Figa wrote: We are using uImages built with same parameters as those used in simple 'make uImage', just with a DTB appended to zImage before running mkimage on it. note that the parameters used for $(make uImage) are not optimal, only safe. They use (letting the MMU aside) the link address of the final image as load address. That means as U-Boot probably didn't choose the right address when reading the image it has to move it to the link address and then jumps into it. Then the decompressor notices that the compressed image is located where the decompressed image should go to and so has to move the image again. So you could save quite some time during boot if you'd teach U-Boot that it can just use the image where it was loaded to. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] pci: Provide support for parsing PCI DT ranges property
On Thu, Dec 20, 2012 at 08:25:00AM +, Thierry Reding wrote: On Wed, Dec 12, 2012 at 04:37:50PM +, Andrew Murray wrote: [...] diff --git a/drivers/of/address.c b/drivers/of/address.c [...] + start = of_get_property(node, ranges, rlen); + if (start == NULL) + return NULL; + + end = start + rlen; I'm currently rewriting large parts of the Tegra PCIe controller driver and I'm trying to use this new API. This seems to work fine, except that I think this line needs to be: end = start + rlen / sizeof(__be32); Otherwise we'll try to process 4 times as many ranges as there are. Thierry Good catch. Thanks for taking this on. Andrew Murray ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: PMU node location
On Sat, Jan 12, 2013 at 03:54:42PM +, Rob Herring wrote: On 01/10/2013 07:47 AM, Michal Simek wrote: Hi Rob, Mark, Grant and others, I want to check with you the location of ARM pmu node I see that 1) highbank and dbx5x0 have it in soc node 2) vexpress and tegra have no main bus and pmu is in root like all others devices. (Any reason no to have main bus? Does it mean that there is no bus or that all devices are accessible?) That seems really wrong in general. Any memory mapped device is on a bus of some kind. I'm not sure the reasoning. Perhaps Stephen can explain. 3) omap2/omap3 have added pmu node to root node(mailing list) 4) Just for completeness no platform has it in the bus. That's why I have obvious question what it is proper location for pmu node? Obviously, highbank is the true and correct way. ;) The pmu is part of the cpu, so it could be part of /cpus. That may cause problems having non-cpu nodes and it would not get probed (although technically that is a Linux problem and should not influence the DT). If we were going to allow cpu nodes in /cpus, I'd rather we supported a pmu node in each /cpus/cpuN node. That way the description of heterogeneous clusters would be intuitive (each pmu node representing a single cpu-affine unit rather than the collection of all cpu-affine units). That way describing heterogeneous clusters would become intuitive (cpu affinity would be implicit, and wouldn't have to be described separately as with my proposed binding [1]). and I'm not sure how you'd handle PMUs which used the same PPI Since it is not on a bus, then putting it at the top level probably makes more sense than on a bus. Agreed. I think this makes the most sense. Rob Thanks, Michal Thanks, Mark. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137290.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: tegra: Use DT /cpu node to detect number of CPU core
On Mon, Jan 14, 2013 at 09:52:50AM +0200, Hiroshi Doyu wrote: + if (!arm_dt_cpu_map_valid()) + set_cpu_possible(0, true); You don't need to do any of this (and, therefore, I don't think you even need the first patch.) The generic boot code will set CPU0 as possible, present and online. Think about it: you're booting on that very CPU so it better be possible, present and online. If it isn't, what CPU is executing your code? arm_dt_init_cpu_maps() will only ever set _additional_ CPUs in the possible map. Ergo, by the time the above code is run, CPU0 will already be marked as possible. Therefore, the above code and arm_dt_cpu_map_valid() is not required. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] pci: Provide support for parsing PCI DT ranges property
On Sat, Dec 15, 2012 at 01:06:41AM +, Grant Likely wrote: On Wed, Dec 12, 2012 at 4:37 PM, Andrew Murray andrew.mur...@arm.com wrote: DT bindings for PCI host bridges often use the ranges property to describe memory and IO ranges - this binding tends to be the same across architectures yet several parsing implementations exist, e.g. arch/mips/pci/pci.c, arch/powerpc/kernel/pci-common.c, arch/sparc/kernel/pci.c and arch/microblaze/pci/pci-common.c (clone of PPC). Some of these duplicate functionality provided by drivers/of/address.c. Hi Andrew, Thanks for looking into this. This definitely needs to be done. However, I cannot merge this patch as-is because it actually makes things worse by adding yet another implementation of the parsing code. Plus it doesn't actually have any users. :-) I understand. Though I see Thierry has included this in his patch set - I guess that means there is potentially one user now :). Instead, move the existing code that you need out of arch/powerpc/kernel/pci-common.c into a shared place and add in the features you need. Bonus points if you fixup microblaze or others at the same time. In most part the patch I submitted was the common code from powerpc but without quirks and tie-ins to powerpc structures. I'd like to convert powerpc to using my patch and others but won't get time to do this at present :( g. Andrew Murray ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: PMU node location
2013/1/14 Mark Rutland mark.rutl...@arm.com:
On Sat, Jan 12, 2013 at 03:54:42PM +, Rob Herring wrote:
On 01/10/2013 07:47 AM, Michal Simek wrote:
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node
I see that
1) highbank and dbx5x0 have it in soc node
2) vexpress and tegra have no main bus and pmu is in root like all
others devices.
(Any reason no to have main bus? Does it mean that there is no bus or
that all
devices are accessible?)
That seems really wrong in general. Any memory mapped device is on a bus
of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
3) omap2/omap3 have added pmu node to root node(mailing list)
4) Just for completeness no platform has it in the bus.
That's why I have obvious question what it is proper location for pmu node?
Obviously, highbank is the true and correct way. ;)
The pmu is part of the cpu, so it could be part of /cpus. That may cause
problems having non-cpu nodes and it would not get probed (although
technically that is a Linux problem and should not influence the DT).
If we were going to allow cpu nodes in /cpus, I'd rather we supported a pmu
node in each /cpus/cpuN node. That way the description of heterogeneous
clusters would be intuitive (each pmu node representing a single cpu-affine
unit rather than the collection of all cpu-affine units). That way describing
heterogeneous clusters would become intuitive (cpu affinity would be implicit,
and wouldn't have to be described separately as with my proposed binding [1]).
and I'm not sure how you'd handle PMUs which used the same PPI
This is the same as is done with mpcore private timers which uses the same
PPI. Based on gic binding it is solved by 3rd cell (flags) bits[15:8]
PPI interrupt cpu mask
This also open one more question for me because we have mpcore timers
on the bus but they are in mpcore. They should be also moved to /cpu/cpuN node.
ps7_scutimer_0: ps7-scutimer@f8f00600 {
compatible = xlnx,ps7-scutimer-1.00.a,
arm,cortex-a9-twd-timer;
interrupt-parent = ps7_scugic_0;
interrupts = 1 13 0x0301;
reg = 0xf8f00600 0x20 ;
} ;
btw: what is the main reason for Soc node name? Because of
highbank.dts includes ecx-common.dtsi
where soc is used as bus.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: tegra: Use DT /cpu node to detect number of CPU core
Hi Russell,
Russell King - ARM Linux li...@arm.linux.org.uk wrote @ Mon, 14 Jan 2013
10:27:20 +0100:
On Mon, Jan 14, 2013 at 09:52:50AM +0200, Hiroshi Doyu wrote:
+ if (!arm_dt_cpu_map_valid())
+ set_cpu_possible(0, true);
You don't need to do any of this (and, therefore, I don't think you even
need the first patch.)
The generic boot code will set CPU0 as possible, present and online. Think
about it: you're booting on that very CPU so it better be possible, present
and online. If it isn't, what CPU is executing your code?
arm_dt_init_cpu_maps() will only ever set _additional_ CPUs in the possible
map.
Ergo, by the time the above code is run, CPU0 will already be marked as
possible. Therefore, the above code and arm_dt_cpu_map_valid() is not
required.
Right.
In Tegra, we've decided to not use SCU based detection at all any more
and to continue with a single core even when DT cpu detection
fails. For Tegra, arm_dt_cpu_map_valid() is not necessary. For other
SoCs, this would be necessary when they want to detect again with
SCU.
Now this original Tegra patch would be independet of the 1st patch as
below:
From 36061aff7a772524a1d1785884889619042d4445 Mon Sep 17 00:00:00 2001
From: Hiroshi Doyu hd...@nvidia.com
Date: Mon, 26 Nov 2012 12:25:14 +0200
Subject: [PATCH 1/1] ARM: tegra: Use DT /cpu node to detect number of CPU
core
SCU based detection only works with Cortex-A9 MP and it doesn't
support ones with multiple clusters. The only way to detect number of
CPU core correctly is with DT /cpu node.
Tegra SoCs decided to use DT detection as the only way and to not use
SCU based detection at all. Even if DT /cpu node based detection
fails, it continues with a single core
Signed-off-by: Hiroshi Doyu hd...@nvidia.com
---
Based on the discussion:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140608.html
---
arch/arm/mach-tegra/platsmp.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 6867030..689ee4b 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -177,23 +177,8 @@ done:
return status;
}
-/*
- * Initialise the CPU possible map early - this describes the CPUs
- * which may be present or become present in the system.
- */
static void __init tegra_smp_init_cpus(void)
{
- unsigned int i, ncores = scu_get_core_count(scu_base);
-
- if (ncores nr_cpu_ids) {
- pr_warn(SMP: %u cores greater than maximum (%u), clipping\n,
- ncores, nr_cpu_ids);
- ncores = nr_cpu_ids;
- }
-
- for (i = 0; i ncores; i++)
- set_cpu_possible(i, true);
-
set_smp_cross_call(gic_raise_softirq);
}
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
On Sun, Jan 13, 2013 at 09:58:06AM +, Thierry Reding wrote: On Sat, Jan 12, 2013 at 09:12:25PM +, Arnd Bergmann wrote: On Saturday 12 January 2013, Thierry Reding wrote: I already hinted at that in one of the other subthreads. Having such a multiplex would also allow the driver to be built as a module. I had already thought about this when I was working on an earlier version of these patches. Basically these would be two ops attached to the host bridge, and the generic arch_setup_msi_irq() could then look that up given the struct pci_dev that is passed to it and call this new per- host bridge .setup_msi_irq(). struct pci_ops looks like a good place to put these. They'll be available from each struct pci_bus, so should be easy to call from arch_setup_msi_irq(). Any objections? struct pci_ops has a long history of being specifically about config space read/write operations, so on the one hand it does not feel like the right place to put interrupt specific operations, but on the other hand, the name sounds appropriate and I cannot think of any other place to put this, so it's fine with me. The only alternative I can think of is to introduce a new structure next to it in struct pci_bus, but that feels a bit pointless. Maybe Bjorn has a preference one way or the other. The name pci_ops is certainly generic enough. Also the comment above the structure declaration says Low-level architecture-dependent routines, which applies to the MSI functions as well. I've previously looked into this. It seems that architectures handle this in different ways, some use vector tables, others use a multiplex and others just let the end user implement the callback directly. I've made an attempt to find a more common way. Though my implementation, which I will try to share later today for reference provides a registration function in drivers/pci/msi.c to provide implementations of the (setup|teardown)_msi_irq(s) ops. This seems slightly better than the current approach and doesn't break existing users - but is still ugly. At present the PCI and MSI frameworks are largely uncoupled from each other and so I was keen to not pollute PCI structures (e.g. pci_ops) with MSI ops. Just because most PCI host bridges also provide MSI support I don't think there is a reason why they should always come as a pair or be provided by the same chip. Perhaps the solution is to support MSI controller drivers and a means to associate them with PCI host controller drivers? Andrew Murray ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 02/11] ARM: nomadik: initial devicetree support
On Mon, Jan 14, 2013 at 07:02:06AM +, Linus Walleij wrote:
On Fri, Jan 11, 2013 at 6:57 PM, Mark Rutland mark.rutl...@arm.com wrote:
On Fri, Jan 11, 2013 at 05:04:11PM +, Grant Likely wrote:
On Tue, 8 Jan 2013 09:57:29 +, Mark Rutland mark.rutl...@arm.com
wrote:
Maybe I've misunderstood how this is laid out, but I can't see where we
get a
cpus node from in the board's dts. Has this just been forgotten?
A cpus node isn't required if it doesn't provide any non-discoverable
information.
Seeing the discussion around the Tegra #CPUs detection code, I'd think we
should have one:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/140209.html
Sorry I cannot figure out how to handle this request.
The Nomadik has one (1) ARM926EJ-S CPU.
Oh! I hadn't realised the Nomadik was v5. The above will be completely
irrelevant. Sorry for wasting everyone's timer over this.
In way of an explanation, further down the thread [1,2] it becomes a discussion
of /cpus node requirements. The long and short of it is that for v{6,7} there's
no standard way of detecting the number of CPUs, and no way of detecting the
CPU IDs (MPIDR.Aff{2,1,0}), so we should always describe this in dt.
For v5 this is indeed useless.
Currently there is no other uniprocessor machine in arch/arm/* doing this,
so have I understood it correctly that you are asking me to do something
that has never been done before, and that all the existing device tree
implementations should also do this in the end?
I think all v6+ platforms should have /cpus/cpu@N nodes for consistency across
UP and SMP systems. For v{4,5}, this isn't really necessary, unless people want
to conform to the letter of the law from ePAPR (A cpus node is required for
all device trees.). I'm not too worried about this.
The references discussion introduce ARM_CPU_PART_CORTEX_A15
and ARM_CPU_PART_CORTEX_A9 and these are vastly newer
systems than the Nomadik, there is no handling of the older CPU types.
Sorry, I should've linked to the more relevant parts of the thread [1,2].
Are you asking for some new infrastructure to support, mainly for
the sake of itself (like the nice completeness of the device tre), cpu
nodes in these device trees?
I was asking for a /cpus/cpu node, but as you've pointed out this is a v5
platform, and as such this isn't needed.
Does this reasoning also extend to the MIPS, PPC and Sun use of
device trees as well then, as they don't do that, or do you mean this
should be done only for the ARM family?
As you see I don't quite get it, could you elaborate?
Hopefully the above explanation makes sense?
Yours,
Linus Walleij
Thanks,
Mark.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: PMU node location
On Mon, Jan 14, 2013 at 09:36:10AM +, Michal Simek wrote:
2013/1/14 Mark Rutland mark.rutl...@arm.com:
On Sat, Jan 12, 2013 at 03:54:42PM +, Rob Herring wrote:
On 01/10/2013 07:47 AM, Michal Simek wrote:
Hi Rob, Mark, Grant and others,
I want to check with you the location of ARM pmu node
I see that
1) highbank and dbx5x0 have it in soc node
2) vexpress and tegra have no main bus and pmu is in root like all
others devices.
(Any reason no to have main bus? Does it mean that there is no bus or
that all
devices are accessible?)
That seems really wrong in general. Any memory mapped device is on a bus
of some kind. I'm not sure the reasoning. Perhaps Stephen can explain.
3) omap2/omap3 have added pmu node to root node(mailing list)
4) Just for completeness no platform has it in the bus.
That's why I have obvious question what it is proper location for pmu
node?
Obviously, highbank is the true and correct way. ;)
The pmu is part of the cpu, so it could be part of /cpus. That may cause
problems having non-cpu nodes and it would not get probed (although
technically that is a Linux problem and should not influence the DT).
If we were going to allow cpu nodes in /cpus, I'd rather we supported a pmu
node in each /cpus/cpuN node. That way the description of heterogeneous
clusters would be intuitive (each pmu node representing a single cpu-affine
unit rather than the collection of all cpu-affine units). That way
describing
heterogeneous clusters would become intuitive (cpu affinity would be
implicit,
and wouldn't have to be described separately as with my proposed binding
[1]).
and I'm not sure how you'd handle PMUs which used the same PPI
This is the same as is done with mpcore private timers which uses the same
PPI. Based on gic binding it is solved by 3rd cell (flags) bits[15:8]
PPI interrupt cpu mask
What I meant was that for PPIs, you have to use the percpu_irq functions,
requesting each PPI irq once globally, then enabling it on a subset of all
cores. You have to be very careful to ensure you don't attempt to request the
same PPI twice. For example you might have different PPIs in different
clusters, and you have no guarantee that the nodes sharing the same PPI are
grouped together in any consistent order. Ensuring that you've dealt with all
nodes and not double-requested an irq is going to get messy.
This also open one more question for me because we have mpcore timers
on the bus but they are in mpcore. They should be also moved to /cpu/cpuN
node.
If we're doing this it'd probably be good to have some common framework with
the PMU code for handling both cpu-affine description and global description in
the root of the tree. We have to be careful to ensure we don't break current
device trees.
ps7_scutimer_0: ps7-scutimer@f8f00600 {
compatible = xlnx,ps7-scutimer-1.00.a,
arm,cortex-a9-twd-timer;
interrupt-parent = ps7_scugic_0;
interrupts = 1 13 0x0301;
reg = 0xf8f00600 0x20 ;
} ;
btw: what is the main reason for Soc node name? Because of
highbank.dts includes ecx-common.dtsi
where soc is used as bus.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian
Thanks,
Mark.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] gpio: introduce descriptor-based interface
On 01/10/2013 07:08 PM, Arnd Bergmann wrote: I've tried to find platforms that don't yet use GPIOLIB and fortunately there are very few left: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. I performed a search on my side too (checking configurations options which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the same list. This takes some time btw - many platforms use this combo to make GPIO support optional. Can I ask how you figured out these two archs? I'd assume the overhead induced by forcibly compiling GPIOlib is neglectable, but let's make sure this is ok indeed - Mike, Geert, would you mind if selecting GENERIC_GPIO enforced GPIOlib to be compiled in, effectively making it mandatory to implement the generic GPIO interface using GPIOlib? Both your implementations support GPIOlib already, but can also work without it, and that would make that possibility obsolete. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. AFAICT these all implement an inline path that bypasses GPIOlib when the GPIO number is known at compile time, for faster bitbanging I presume. It should be totally harmless to keep them. Unfortunately, I don't think it would be possible to have a similar trick using handlers. Thanks, Alex. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/6] ARM: common: vic: Parse interrupt and resume masks from device tree
Hi Rob,
2013/1/14 Rob Herring robherri...@gmail.com:
On 01/12/2013 07:10 PM, Tomasz Figa wrote:
This patch extends vic_of_init to parse valid interrupt sources
and resume sources masks from device tree.
If mask values are not specified in device tree, all sources
are assumed to be valid, as before this patch.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
Documentation/devicetree/bindings/arm/vic.txt | 6 ++
arch/arm/common/vic.c | 7 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/vic.txt
b/Documentation/devicetree/bindings/arm/vic.txt
index 266716b..bb7137c 100644
--- a/Documentation/devicetree/bindings/arm/vic.txt
+++ b/Documentation/devicetree/bindings/arm/vic.txt
@@ -18,6 +18,9 @@ Required properties:
Optional properties:
- interrupts : Interrupt source for parent controllers if the VIC is nested.
+- interrupt-mask : Bit mask of valid interrupt sources (defaults to all
valid)
Can you explain why this is needed and is not just the OR of all
interrupts described in the DT?
Well, it depends what you mean with interrupts described in the DT.
Basically this mask is used for sanity checks of request_irq calls,
by denying interrupts non-existent on given platform.
+- wakeup-mask : Bit mask of interrupt sources that can wake up the system
+ (defaults to all allowed)
Seems like this would be all VIC interrupts unless the wake-up handling
is done in some shadow controller. If the former is true, then wake-up
capability is really a property of individual devices. If the later,
then this property would belong in that shadow controller.
Yes, there is a shadow controller used for configuring which of the available
wake-up signals shall be used.
Still, I don't see how I should model it in the device tree, since its VIC whose
set_irq_wake callback is called.
Before Device Tree, both interrupt and wake-up masks were being passed
as arguments to vic_init function. This is what made me add them as
DT attributes of VIC.
Best regards,
Tomasz Figa
P.S. Rob, sorry for the original message. I have clicked reply
instead of reply to all in the mobile GMail client.
Rob
Example:
@@ -26,4 +29,7 @@ Example:
interrupt-controller;
#interrupt-cells = 1;
reg = 0x6 0x1000;
+
+ interrupt-mask = 0xff7f;
+ wakeup-mask = 0xff7f;
};
diff --git a/arch/arm/common/vic.c b/arch/arm/common/vic.c
index e4df17c..c2889da 100644
--- a/arch/arm/common/vic.c
+++ b/arch/arm/common/vic.c
@@ -407,6 +407,8 @@ void __init vic_init(void __iomem *base, unsigned int
irq_start,
int __init vic_of_init(struct device_node *node, struct device_node *parent)
{
void __iomem *regs;
+ u32 interrupt_mask = ~0;
+ u32 wakeup_mask = ~0;
if (WARN(parent, non-root VICs are not supported))
return -EINVAL;
@@ -415,10 +417,13 @@ int __init vic_of_init(struct device_node *node,
struct device_node *parent)
if (WARN_ON(!regs))
return -EIO;
+ of_property_read_u32(node, interrupt-mask, interrupt_mask);
+ of_property_read_u32(node, wakeup-mask, wakeup_mask);
+
/*
* Passing -1 as first IRQ makes the simple domain allocate descriptors
*/
- __vic_init(regs, -1, ~0, ~0, node);
+ __vic_init(regs, -1, interrupt_mask, wakeup_mask, node);
return 0;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] gpio: introduce descriptor-based interface
On Monday 14 January 2013, Alex Courbot wrote: On 01/10/2013 07:08 PM, Arnd Bergmann wrote: I found two that provide the generic gpio interfaces when gpiolib is disabled, but use gpiolib otherwise for the same hardware, arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h. I would assume that we can simply remove the non-gpiolib shortcut here at cost of a small overhead. I performed a search on my side too (checking configurations options which select GENERIC_GPIO but not ARCH_REQUIRE_GPIOLIB) and found the same list. This takes some time btw - many platforms use this combo to make GPIO support optional. Can I ask how you figured out these two archs? I basically grepped for GENERIC_GPIO and looked at the individual implementations. Then there are a bunch that use gpiolib but have a nontrivial implementation of gpio_get_value and other functions. I'm not sure if these are a problematic with your code. AFAICT these all implement an inline path that bypasses GPIOlib when the GPIO number is known at compile time, for faster bitbanging I presume. It should be totally harmless to keep them. Unfortunately, I don't think it would be possible to have a similar trick using handlers. Right, makes sense. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v7 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
This patch adds host phy support to samsung-usbphy driver and further adds support for samsung's exynos5250 usb-phy. Signed-off-by: Praveen Paneri p.pan...@samsung.com Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- Changes from v6: - Changing macro names from 'HOST_CTRL0_FSEL_CLKSEL_XX' to 'FSEL_CLKSEL_XX' since it's being used by HOST and OTG block to prepare reference clock. - Directly Assigning 'FSEL_CLKSEL_XX' to refclk_freq in samsung_usbphy_get_refclk_freq() instead of ORing them since we are anyways using macros: HOST_CTRL0_FSEL(_x)((_x) 16) OTG_SYS_FSEL(_x) ((_x) 4) .../devicetree/bindings/usb/samsung-usbphy.txt | 12 +- drivers/usb/phy/Kconfig|2 +- drivers/usb/phy/samsung-usbphy.c | 513 ++-- 3 files changed, 496 insertions(+), 31 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt index 22d06cf..0331949 100644 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt @@ -1,15 +1,23 @@ * Samsung's usb phy transceiver -The Samsung's phy transceiver is used for controlling usb otg phy for -s3c-hsotg usb device controller. +The Samsung's phy transceiver is used for controlling usb phy for +s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers +across Samsung SOCs. TODO: Adding the PHY binding with controller(s) according to the under developement generic PHY driver. Required properties: + +Exynos4210: - compatible : should be samsung,exynos4210-usbphy - reg : base physical address of the phy registers and length of memory mapped region. +Exynos5250: +- compatible : should be samsung,exynos5250-usbphy +- reg : base physical address of the phy registers and length of memory mapped + region. + Optional properties: - #address-cells: should be '1' when usbphy node has a child node with 'reg' property. diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig index 36a85b6..fae4d08 100644 --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -48,7 +48,7 @@ config USB_RCAR_PHY config SAMSUNG_USBPHY bool Samsung USB PHY controller Driver - depends on USB_S3C_HSOTG + depends on USB_S3C_HSOTG || USB_EHCI_S5P || USB_OHCI_EXYNOS select USB_OTG_UTILS help Enable this to support Samsung USB phy controller for samsung diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c index 7eec7c3..355c6b2 100644 --- a/drivers/usb/phy/samsung-usbphy.c +++ b/drivers/usb/phy/samsung-usbphy.c @@ -5,7 +5,8 @@ * * Author: Praveen Paneri p.pan...@samsung.com * - * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller + * Samsung USB2.0 PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and + * OHCI-EXYNOS controllers. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -21,11 +22,13 @@ #include linux/platform_device.h #include linux/clk.h #include linux/delay.h +#include linux/device.h #include linux/err.h #include linux/io.h #include linux/of.h #include linux/of_address.h #include linux/usb/otg.h +#include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h /* Register definitions */ @@ -57,24 +60,132 @@ #define RSTCON_HLINK_SWRST (0x1 1) #define RSTCON_SWRST (0x1 0) +/* EXYNOS5 */ +#define EXYNOS5_PHY_HOST_CTRL0 (0x00) + +#define HOST_CTRL0_PHYSWRSTALL (0x1 31) + +#define HOST_CTRL0_REFCLKSEL_MASK (0x3 19) +#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 19) +#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 19) +#define HOST_CTRL0_REFCLKSEL_CLKCORE (0x2 19) + +#define HOST_CTRL0_FSEL_MASK (0x7 16) +#define HOST_CTRL0_FSEL(_x)((_x) 16) + +#define FSEL_CLKSEL_50M(0x7) +#define FSEL_CLKSEL_24M(0x5) +#define FSEL_CLKSEL_20M(0x4) +#define FSEL_CLKSEL_19200K (0x3) +#define FSEL_CLKSEL_12M(0x2) +#define FSEL_CLKSEL_10M(0x1) +#define FSEL_CLKSEL_9600K (0x0) + +#define HOST_CTRL0_TESTBURNIN (0x1 11) +#define HOST_CTRL0_RETENABLE (0x1 10) +#define HOST_CTRL0_COMMONON_N (0x1 9) +#define HOST_CTRL0_SIDDQ (0x1 6) +#define HOST_CTRL0_FORCESLEEP (0x1 5) +#define HOST_CTRL0_FORCESUSPEND(0x1 4) +#define HOST_CTRL0_WORDINTERFACE (0x1 3) +#define
Re: [PATCH 2/2] ARM: tegra: Use DT /cpu node to detect number of CPU core
On Mon, Jan 14, 2013 at 09:49:25AM +, Hiroshi Doyu wrote: Hi Russell, Russell King - ARM Linux li...@arm.linux.org.uk wrote @ Mon, 14 Jan 2013 10:27:20 +0100: On Mon, Jan 14, 2013 at 09:52:50AM +0200, Hiroshi Doyu wrote: + if (!arm_dt_cpu_map_valid()) + set_cpu_possible(0, true); You don't need to do any of this (and, therefore, I don't think you even need the first patch.) The generic boot code will set CPU0 as possible, present and online. Think about it: you're booting on that very CPU so it better be possible, present and online. If it isn't, what CPU is executing your code? arm_dt_init_cpu_maps() will only ever set _additional_ CPUs in the possible map. Ergo, by the time the above code is run, CPU0 will already be marked as possible. Therefore, the above code and arm_dt_cpu_map_valid() is not required. Right. In Tegra, we've decided to not use SCU based detection at all any more and to continue with a single core even when DT cpu detection fails. For Tegra, arm_dt_cpu_map_valid() is not necessary. For other SoCs, this would be necessary when they want to detect again with SCU. Correct. I will keep my patch around and repost it if and when we want other platforms to rely on legacy HW number of cores count discovery. Given that's going to be temporary legacy code anyway, I hope we won't need it at all. Lorenzo ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/2] Adding USB 3.0 DRD-phy support for exynos5250
Changes from v2: - Renaming 'samsung-usbphy.c' driver to 'samsung-usb2.c' indicating usb 2.0 phy controller's driver for Samsung's SoCs. - Moving the register definitions and strcuture definitions to common header file 'samsung-usbphy.h' to be used across usb 2.0 and usb 3.0 phy. - Keeping common exported function definitions in samsung-usbphy.c which can be used across usb 2.0 and usb 3.0 phy. - Writting separate driver file for Samsung's USB 3.0 phy controller. and making it dependent on USB_DWC3. Rebased on top of usb-next followed by following patches/patch-threads: -- [PATCH v9 1/2] usb: phy: samsung: Introducing usb phy driver for hsotg -- [PATCH] usb: phy: samsung: Add support to set pmu isolation (version 6) -- [PATCH v6 0/4] Adding usb2.0 host-phy support for exynos5250 Changes form v1: - Moved architecture related patch out of this patch-set. - Replaced unnecessary multi-line macro definitions by single line definitions. - Creating new data structure for USB 3.0 phy type and embedding it in 'samsung_usbphy' structure. - Adding a flag in 'samsung_usbphy' structure to check if device has usb 3.0 type phy or not. - Restructuring probe sequence for USB 3.0 phy, such that we are initializing only when device has usb3.0 type phy. Vivek Gautam (2): usb: phy: samsung: Common out the generic stuff usb: phy: samsung: Add PHY support for USB 3.0 controller drivers/usb/phy/Kconfig |8 + drivers/usb/phy/Makefile |3 +- drivers/usb/phy/samsung-usb2.c | 511 +++ drivers/usb/phy/samsung-usb3.c | 349 +++ drivers/usb/phy/samsung-usbphy.c | 713 +- drivers/usb/phy/samsung-usbphy.h | 328 + 6 files changed, 1205 insertions(+), 707 deletions(-) create mode 100644 drivers/usb/phy/samsung-usb2.c create mode 100644 drivers/usb/phy/samsung-usb3.c create mode 100644 drivers/usb/phy/samsung-usbphy.h -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 1/2] usb: phy: samsung: Common out the generic stuff
Moving register and structure definitions to header file,
and keeping the generic functions to be used across
multiple PHYs in common file samsung-usbphy.c.
Also renaming the usb 2.0 phy driver to samsung-usb2.c
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/phy/Makefile |2 +-
drivers/usb/phy/samsung-usb2.c | 511 +++
drivers/usb/phy/samsung-usbphy.c | 713 +-
drivers/usb/phy/samsung-usbphy.h | 247 +
4 files changed, 766 insertions(+), 707 deletions(-)
create mode 100644 drivers/usb/phy/samsung-usb2.c
create mode 100644 drivers/usb/phy/samsung-usbphy.h
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index ec304f6..0f4fd4f 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -9,4 +9,4 @@ obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
-obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
+obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o samsung-usb2.o
diff --git a/drivers/usb/phy/samsung-usb2.c b/drivers/usb/phy/samsung-usb2.c
new file mode 100644
index 000..ffde341
--- /dev/null
+++ b/drivers/usb/phy/samsung-usb2.c
@@ -0,0 +1,511 @@
+/* linux/drivers/usb/phy/samsung-usbphy.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Praveen Paneri p.pan...@samsung.com
+ *
+ * Samsung USB2.0 PHY transceiver; talks to S3C HS OTG controller, EHCI-S5P and
+ * OHCI-EXYNOS controllers.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/of.h
+#include linux/usb/otg.h
+#include linux/usb/samsung_usb_phy.h
+#include linux/platform_data/samsung-usbphy.h
+
+#include samsung-usbphy.h
+
+int samsung_usbphy_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+ if (!otg)
+ return -ENODEV;
+
+ if (!otg-host)
+ otg-host = host;
+
+ return 0;
+}
+
+static bool exynos5_phyhost_is_on(void *regs)
+{
+ u32 reg;
+
+ reg = readl(regs + EXYNOS5_PHY_HOST_CTRL0);
+
+ return !(reg HOST_CTRL0_SIDDQ);
+}
+
+static void samsung_exynos5_usbphy_enable(struct samsung_usbphy *sphy)
+{
+ void __iomem *regs = sphy-regs;
+ u32 phyclk = sphy-ref_clk_freq;
+ u32 phyhost;
+ u32 phyotg;
+ u32 phyhsic;
+ u32 ehcictrl;
+ u32 ohcictrl;
+
+ /*
+* phy_usage helps in keeping usage count for phy
+* so that the first consumer enabling the phy is also
+* the last consumer to disable it.
+*/
+
+ atomic_inc(sphy-phy_usage);
+
+ if (exynos5_phyhost_is_on(regs)) {
+ dev_info(sphy-dev, Already power on PHY\n);
+ return;
+ }
+
+ /* Host configuration */
+ phyhost = readl(regs + EXYNOS5_PHY_HOST_CTRL0);
+
+ /* phy reference clock configuration */
+ phyhost = ~HOST_CTRL0_FSEL_MASK;
+ phyhost |= HOST_CTRL0_FSEL(phyclk);
+
+ /* host phy reset */
+ phyhost = ~(HOST_CTRL0_PHYSWRST |
+ HOST_CTRL0_PHYSWRSTALL |
+ HOST_CTRL0_SIDDQ |
+ /* Enable normal mode of operation */
+ HOST_CTRL0_FORCESUSPEND |
+ HOST_CTRL0_FORCESLEEP);
+
+ /* Link reset */
+ phyhost |= (HOST_CTRL0_LINKSWRST |
+ HOST_CTRL0_UTMISWRST |
+ /* COMMON Block configuration during suspend */
+ HOST_CTRL0_COMMONON_N);
+ writel(phyhost, regs + EXYNOS5_PHY_HOST_CTRL0);
+ udelay(10);
+ phyhost = ~(HOST_CTRL0_LINKSWRST |
+ HOST_CTRL0_UTMISWRST);
+ writel(phyhost, regs + EXYNOS5_PHY_HOST_CTRL0);
+
+ /* OTG configuration */
+ phyotg = readl(regs + EXYNOS5_PHY_OTG_SYS);
+
+ /* phy reference clock configuration */
+ phyotg = ~OTG_SYS_FSEL_MASK;
+ phyotg |= OTG_SYS_FSEL(phyclk);
+
+ /* Enable normal mode of operation */
+ phyotg = ~(OTG_SYS_FORCESUSPEND |
+ OTG_SYS_SIDDQ_UOTG |
+ OTG_SYS_FORCESLEEP |
+ OTG_SYS_REFCLKSEL_MASK |
+ /* COMMON Block configuration
[PATCH v3 2/2] usb: phy: samsung: Add PHY support for USB 3.0 controller
Adding PHY driver support for USB 3.0 controller for Samsung's
SoCs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/phy/Kconfig |8 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/samsung-usb3.c | 349 ++
drivers/usb/phy/samsung-usbphy.h | 81 +
4 files changed, 439 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/phy/samsung-usb3.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index fae4d08..a7b0536 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -53,3 +53,11 @@ config SAMSUNG_USBPHY
help
Enable this to support Samsung USB phy controller for samsung
SoCs.
+
+config SAMSUNG_USB3PHY
+ bool Samsung USB 3.0 PHY controller Driver
+ depends on USB_DWC3
+ select USB_OTG_UTILS
+ help
+ Enable this to support Samsung USB 3.0 phy controller for samsung
+ SoCs.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 0f4fd4f..ed28e89 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
obj-$(CONFIG_USB_RCAR_PHY) += rcar-phy.o
obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o samsung-usb2.o
+obj-$(CONFIG_SAMSUNG_USB3PHY) += samsung-usb3.o
diff --git a/drivers/usb/phy/samsung-usb3.c b/drivers/usb/phy/samsung-usb3.c
new file mode 100644
index 000..8029c1b
--- /dev/null
+++ b/drivers/usb/phy/samsung-usb3.c
@@ -0,0 +1,349 @@
+/* linux/drivers/usb/phy/samsung-usb3.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Vivek Gautam gautam.vi...@samsung.com
+ *
+ * Samsung USB 3.0 PHY transceiver; talks to DWC3 controller.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+#include linux/of.h
+#include linux/usb/samsung_usb_phy.h
+#include linux/platform_data/samsung-usbphy.h
+
+#include samsung-usbphy.h
+
+/*
+ * Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock
core.
+ */
+static u32 samsung_usb3_phy_set_refclk(struct samsung_usbphy *sphy)
+{
+ u32 reg;
+ u32 refclk;
+
+ refclk = sphy-ref_clk_freq;
+
+ reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
+ PHYCLKRST_FSEL(refclk);
+
+ switch (refclk) {
+ case FSEL_CLKSEL_50M:
+ reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
+ PHYCLKRST_SSC_REFCLKSEL(0x00));
+ break;
+ case FSEL_CLKSEL_20M:
+ reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
+ PHYCLKRST_SSC_REFCLKSEL(0x00));
+ break;
+ case FSEL_CLKSEL_19200K:
+ reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
+ PHYCLKRST_SSC_REFCLKSEL(0x88));
+ break;
+ case FSEL_CLKSEL_24M:
+ default:
+ reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
+ PHYCLKRST_SSC_REFCLKSEL(0x88));
+ break;
+ }
+
+ return reg;
+}
+
+static int samsung_exynos5_usb3_phy_enable(struct samsung_usbphy *sphy)
+{
+ void __iomem *regs = sphy-regs;
+ u32 phyparam0;
+ u32 phyparam1;
+ u32 linksystem;
+ u32 phybatchg;
+ u32 phytest;
+ u32 phyclkrst;
+
+ /* Reset USB 3.0 PHY */
+ writel(0x0, regs + EXYNOS5_DRD_PHYREG0);
+
+ phyparam0 = readl(regs + EXYNOS5_DRD_PHYPARAM0);
+ /* Select PHY CLK source */
+ phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+ /* Set Loss-of-Signal Detector sensitivity */
+ phyparam0 = ~PHYPARAM0_REF_LOSLEVEL_MASK;
+ phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
+ writel(phyparam0, regs + EXYNOS5_DRD_PHYPARAM0);
+
+ writel(0x0, regs + EXYNOS5_DRD_PHYRESUME);
+
+ /*
+* Setting the Frame length Adj value[6:1] to default 0x20
+* See xHCI 1.0 spec, 5.2.4
+*/
+ linksystem = LINKSYSTEM_XHCI_VERSION_CONTROL |
+ LINKSYSTEM_FLADJ(0x20);
+ writel(linksystem, regs + EXYNOS5_DRD_LINKSYSTEM);
+
+ phyparam1 = readl(regs + EXYNOS5_DRD_PHYPARAM1);
+ /* Set Tx De-Emphasis level */
+ phyparam1 = ~PHYPARAM1_PCS_TXDEEMPH_MASK;
+ phyparam1 |= PHYPARAM1_PCS_TXDEEMPH;
+ writel(phyparam1, regs +
Re: [PATCH 2/4] regulator: tps65090: add DT support
On Fri, Dec 28, 2012 at 02:59:39PM +0530, Laxman Dewangan wrote: Add DT support for TI PMIC tps65090 regulator driver. The DT of this device have node regulator and all regulator's node of this device is added under this node. Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com Seems sensible for this to go via MFD given that there's more MFD in the series than regulator. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] mfd: tps65090: remove suspend/resume callbacks
On Fri, Dec 28, 2012 at 02:59:41PM +0530, Laxman Dewangan wrote: The tps65090 mfd driver implement the suspend/resume callbacks which just disable and enable irqs in suspend/resume respectively. This operation is already done in irq suspend and irq_resume and hence it is not require to implement the same in the driver. Remove this non-require code. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
Hello,
This all looks good. I just have a couple of comments about the cpus node.
On Sun, Jan 13, 2013 at 01:10:57AM +, Tomasz Figa wrote:
This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
Since all the SoCs in the series are very similar, the files are created
hierarchically - one file for the whole series and then separate files
for particular SoCs including the common one.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
[...]
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
new file mode 100644
index 000..55d6e08
--- /dev/null
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -0,0 +1,97 @@
+/*
+ * Samsung's S3C64xx SoC series common device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa tomasz.f...@gmail.com
+ *
+ * Samsung's S3C64xx SoC series device nodes are listed in this file.
+ * Particular SoCs from S3C64xx series can include this file and provide
+ * values for SoCs specfic bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C64xx SoCs. As device tree coverage for S3C64xx increases, additional
+ * nodes can be added to this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = arm,arm1176jzf-s;
+ };
+ };
You can drop the unit address from the cpu node - it's meant to be there to
differentiate multiple nodes (and is supposed to match the reg property, which
the 1176jzf-s can't have, as it doesn't have an MPIDR).
Also, arm,arm1176jzf-s isn't listed in the binding doc. There was a question
about how to maintain this list [1], but I can't seem to find a conclusion, if
any were reached. It might be worth appending arm,arm1176 to the compatible
list for the cpu node in case we want to enable something via dt for all 1176
variations.
Dave, Lorenzo, any thoughts?
[...]
Thanks,
Mark.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-November/131362.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] OF: Link platform device resources properly.
On 01/03/2013 04:31 PM, Pantelis Antoniou wrote: The resources of the platform devices created by the OF core were not properly linked. Make sure that they are, so that we don't get any crashes when trying to remove the device. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/of/device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/of/device.c b/drivers/of/device.c index 4c74e4f..d75fcaf 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -62,6 +62,9 @@ int of_device_add(struct platform_device *ofdev) if (!ofdev-dev.parent) set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node)); + /* make sure we add the resources to the appropriate lists */ + platform_device_link_resources(ofdev); + Submit this with the patch that adds this function or state the dependency please. Rob return device_add(ofdev-dev); } ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 5/6] ARM: dts: Add basic dts include files for Samsung S3C64xx SoCs
On Mon, Jan 14, 2013 at 02:48:41PM +, Mark Rutland wrote:
Hello,
This all looks good. I just have a couple of comments about the cpus node.
On Sun, Jan 13, 2013 at 01:10:57AM +, Tomasz Figa wrote:
This patch adds basic device tree definitions for Samsung S3C64xx SoCs.
Since all the SoCs in the series are very similar, the files are created
hierarchically - one file for the whole series and then separate files
for particular SoCs including the common one.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
[...]
diff --git a/arch/arm/boot/dts/s3c64xx.dtsi b/arch/arm/boot/dts/s3c64xx.dtsi
new file mode 100644
index 000..55d6e08
--- /dev/null
+++ b/arch/arm/boot/dts/s3c64xx.dtsi
@@ -0,0 +1,97 @@
+/*
+ * Samsung's S3C64xx SoC series common device tree source
+ *
+ * Copyright (c) 2013 Tomasz Figa tomasz.f...@gmail.com
+ *
+ * Samsung's S3C64xx SoC series device nodes are listed in this file.
+ * Particular SoCs from S3C64xx series can include this file and provide
+ * values for SoCs specfic bindings.
+ *
+ * Note: This file does not include device nodes for all the controllers in
+ * S3C64xx SoCs. As device tree coverage for S3C64xx increases, additional
+ * nodes can be added to this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = arm,arm1176jzf-s;
+ };
+ };
You can drop the unit address from the cpu node - it's meant to be there to
differentiate multiple nodes (and is supposed to match the reg property, which
the 1176jzf-s can't have, as it doesn't have an MPIDR).
Well, this is a point that I should consider since the kernel docs I wrote are
misleading, they require the reg property that can not be there on UP.
True, MPIDR does not exist in this case, but I have to document this in the
bindings since it is unclear.
Also, arm,arm1176jzf-s isn't listed in the binding doc. There was a question
about how to maintain this list [1], but I can't seem to find a conclusion, if
any were reached. It might be worth appending arm,arm1176 to the compatible
list for the cpu node in case we want to enable something via dt for all 1176
variations.
Dave, Lorenzo, any thoughts?
Eh, frankly I do not know how to handle this. Either we add a compatible
string to the bindings anytime a DT gets merged in the kernel but how
to maintain it, it has to be defined. Happy to hear some feedback on
this.
Lorenzo
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation
On Wed, Jan 09, 2013 at 10:23:52AM +0100, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 01:19:39AM -0800, Dmitry Torokhov wrote:
On Wed, Jan 09, 2013 at 08:07:45AM +0100, Thierry Reding wrote:
On Sun, Jan 06, 2013 at 11:57:48AM -0800, Dmitry Torokhov wrote:
On Sun, Jan 06, 2013 at 08:27:39PM +0100, Thierry Reding wrote:
On Sat, Jan 05, 2013 at 12:06:58AM -0800, Dmitry Torokhov wrote:
On Sat, Jan 05, 2013 at 01:15:08PM +0530, Laxman Dewangan wrote:
[...]
@@ -735,25 +738,16 @@ static int tegra_kbc_probe(struct
platform_device *pdev)
spin_lock_init(kbc-lock);
setup_timer(kbc-timer, tegra_kbc_keypress_timer, (unsigned
long)kbc);
- res = request_mem_region(res-start, resource_size(res),
pdev-name);
- if (!res) {
- dev_err(pdev-dev, failed to request I/O memory\n);
- err = -EBUSY;
- goto err_free_mem;
- }
-
- kbc-mmio = ioremap(res-start, resource_size(res));
+ kbc-mmio = devm_request_and_ioremap(pdev-dev, res);
if (!kbc-mmio) {
- dev_err(pdev-dev, failed to remap I/O memory\n);
- err = -ENXIO;
- goto err_free_mem_region;
+ dev_err(pdev-dev, Cannot request memregion/iomap
address\n);
+ return -EADDRNOTAVAIL;
Erm, no, -EBUSY please.
EADDRNOTAVAIL is the canonical error for devm_request_and_ioremap()
failure. The kerneldoc comment in lib/devres.c even gives a short
example that uses this error code.
I am sorry, but I do not consider a function that was added a little
over a year ago as a canon. If you look at the uses of EADDRNOTAVAIL it
is used predominantly in networking code to indicate that attempted
_network_ address is not available.
EBUSY might be misleading, though. devm_request_and_ioremap() can fail
in both the request_mem_region() and ioremap() calls. Furthermore it'd
be good to settle on a consistent error-code instead of doing it
differently depending on subsystem and/or driver. Currently the various
error codes used are:
EBUSY, EADDRNOTAVAIL, ENXIO, ENOMEM, ENODEV, ENOENT, EINVAL,
EIO, EFAULT, EADDRINUSE
Also if we can settle on one error code we should follow up with a patch
to make it consistent across the tree and also update that kerneldoc
comment. I volunteer to do that if nobody else steps up. I'm also Cc'ing
Wolfram (the original author), maybe he has some thoughts on this.
If you going to change all drivers make devm_request_and_ioremap()
return ERR_PTR()-encoded errors and then we can differentiate what
part of it failed.
Yeah, that thought also crossed my mind. I'll give other people some
time to comment before hurling myself into preparing patches.
I've prepared a patch that changes devm_request_and_ioremap() to return
ERR_PTR()-encoded errors and adjusts all callers. As you can imagine it
is a bit on the huge side. scripts/get_maintainer.pl lists 156 people
and mailing lists. I've gone through the list, and as far as I can tell
everyone on that list is actually affected by the patch, so there's not
much potential for tuning it down.
There is also the issue of whose tree this should go into. Unfortunately
the patch can't be broken down into smaller chunks because it changes
how the devm_request_and_ioremap() function's return value is handled in
an incompatible way, so it won't be possible to gradually phase this in.
Furthermore I can imagine that until the end of the release cycle new
code may be added on which the same transformations need to be done. I
have a semantic patch to do the bulk of the work, but quite a bit of
coordination will be required.
I'm adding Arnd and Greg on Cc, maybe they can advise on how best to
handle this kind of patch.
Thierry
pgpUOa8KhkiSg.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation
On Mon, Jan 14, 2013 at 04:49:59PM +0100, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 10:23:52AM +0100, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 01:19:39AM -0800, Dmitry Torokhov wrote:
On Wed, Jan 09, 2013 at 08:07:45AM +0100, Thierry Reding wrote:
On Sun, Jan 06, 2013 at 11:57:48AM -0800, Dmitry Torokhov wrote:
On Sun, Jan 06, 2013 at 08:27:39PM +0100, Thierry Reding wrote:
On Sat, Jan 05, 2013 at 12:06:58AM -0800, Dmitry Torokhov wrote:
On Sat, Jan 05, 2013 at 01:15:08PM +0530, Laxman Dewangan wrote:
[...]
@@ -735,25 +738,16 @@ static int tegra_kbc_probe(struct
platform_device *pdev)
spin_lock_init(kbc-lock);
setup_timer(kbc-timer, tegra_kbc_keypress_timer,
(unsigned long)kbc);
- res = request_mem_region(res-start,
resource_size(res), pdev-name);
- if (!res) {
- dev_err(pdev-dev, failed to request I/O
memory\n);
- err = -EBUSY;
- goto err_free_mem;
- }
-
- kbc-mmio = ioremap(res-start, resource_size(res));
+ kbc-mmio = devm_request_and_ioremap(pdev-dev, res);
if (!kbc-mmio) {
- dev_err(pdev-dev, failed to remap I/O
memory\n);
- err = -ENXIO;
- goto err_free_mem_region;
+ dev_err(pdev-dev, Cannot request
memregion/iomap address\n);
+ return -EADDRNOTAVAIL;
Erm, no, -EBUSY please.
EADDRNOTAVAIL is the canonical error for devm_request_and_ioremap()
failure. The kerneldoc comment in lib/devres.c even gives a short
example that uses this error code.
I am sorry, but I do not consider a function that was added a little
over a year ago as a canon. If you look at the uses of EADDRNOTAVAIL
it
is used predominantly in networking code to indicate that attempted
_network_ address is not available.
EBUSY might be misleading, though. devm_request_and_ioremap() can fail
in both the request_mem_region() and ioremap() calls. Furthermore it'd
be good to settle on a consistent error-code instead of doing it
differently depending on subsystem and/or driver. Currently the various
error codes used are:
EBUSY, EADDRNOTAVAIL, ENXIO, ENOMEM, ENODEV, ENOENT, EINVAL,
EIO, EFAULT, EADDRINUSE
Also if we can settle on one error code we should follow up with a patch
to make it consistent across the tree and also update that kerneldoc
comment. I volunteer to do that if nobody else steps up. I'm also Cc'ing
Wolfram (the original author), maybe he has some thoughts on this.
If you going to change all drivers make devm_request_and_ioremap()
return ERR_PTR()-encoded errors and then we can differentiate what
part of it failed.
Yeah, that thought also crossed my mind. I'll give other people some
time to comment before hurling myself into preparing patches.
I've prepared a patch that changes devm_request_and_ioremap() to return
ERR_PTR()-encoded errors and adjusts all callers. As you can imagine it
is a bit on the huge side. scripts/get_maintainer.pl lists 156 people
and mailing lists. I've gone through the list, and as far as I can tell
everyone on that list is actually affected by the patch, so there's not
much potential for tuning it down.
There is also the issue of whose tree this should go into. Unfortunately
the patch can't be broken down into smaller chunks because it changes
how the devm_request_and_ioremap() function's return value is handled in
an incompatible way, so it won't be possible to gradually phase this in.
Furthermore I can imagine that until the end of the release cycle new
code may be added on which the same transformations need to be done. I
have a semantic patch to do the bulk of the work, but quite a bit of
coordination will be required.
I'm adding Arnd and Greg on Cc, maybe they can advise on how best to
handle this kind of patch.
You should provide a wrapper function that does the correct return
value, convert drivers over to it, and then, when everyone is changed,
drop the old call. To change 156 different drivers all at once, in a
way that is not detectable by the compiler breaking the build, is not a
good thing to do at all.
By doing it in this manner, it will take longer, but you can push the
patches through the different maintainer's trees. If they are slow,
I'll be glad to take the remaining patches in my driver-core tree to do
the final bits.
Hope this helps,
greg k-h
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V7] kbuild: create a rule to run the pre-processor on *.dts files
On 11:43 Wed 02 Jan , Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Create cmd_dtc_cpp to run the C pre-processor on *.dts file before passing them to dtc for final compilation. This allows the use of #define and #include within the .dts file. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Best Regards, J. --- Grant, back in mid-November, you said you'd make a decision on this in the next couple of days, but I think this got overlooked. v7: Build *.dtb from *.dts not src/*.dts. v6: No change. v5: * Update Documentation/kbuild for the new command and rule. v4: * Use -x assembler-with-cpp so pre-defined macros are set up so that #included header files know to only use cpp syntax, not C syntax. * Define __DTS__ for similar reasons. * use $(CPP) not $(CC) -E, and use $(cpp_flags). * Save the pre-processed results so they can be easily inspected when debugging build issues. * The use of -x assembler-with-cpp causes cpp to recognize directives in column 1 only. Hence, there's no need to escape property names that begin with #. Hence, there's no need for separate skeleton.dtsi and skeleton.dtsip. Maintain a separate file extension and build rule so that CPP-usage is opt-in. In particular, when using CPP, #include must be used rather than /include/ so that dependencies work. v3: Pass -x c not -xc to cpp. v2: Place make %.dtb: %.dtsp rule into Makefile.lib. --- Documentation/kbuild/makefiles.txt | 23 +++ scripts/Makefile.lib |9 + 2 files changed, 32 insertions(+) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 14c3f4f..5198b74 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1186,6 +1186,29 @@ When kbuild executes, the following steps are followed (roughly): clean-files += *.dtb DTC_FLAGS ?= -p 1024 +dtc_cpp + This is just like dtc as describe above, except that the C pre- + processor is invoked upon the .dtsp file before compiling the result + with dtc. + + In order for build dependencies to work, all files compiled using + dtc_cpp must use the C pre-processor's #include functionality and not + dtc's /include/ functionality. + + Using the C pre-processor allows use of #define to create named + constants. In turn, the #defines will typically appear in a header + file, which may be shared with regular C code. Since the dtc language + represents a data structure rather than code in C syntax, similar + restrictions are placed on a header file included by a device tree + file as for a header file included by an assembly language file. + In particular, the C pre-processor is passed -x assembler-with-cpp, + which sets macro __ASSEMBLY__. __DTS__ is also set. These allow header + files to restrict their content to that compatible with device tree + source. + + A central rule exists to create $(obj)/%.dtb from $(src)/%.dtsp; + architecture Makefiles do no need to explicitly write out that rule. + --- 6.8 Custom kbuild commands When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index bdf42fd..2c2a302 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -269,6 +269,15 @@ cmd_dtc = $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) -d $(depfile $(obj)/%.dtb: $(src)/%.dts FORCE $(call if_changed_dep,dtc) +dtc-tmp = $(subst $(comma),_,$(dot-target).dts) + +quiet_cmd_dtc_cpp = DTC+CPP $@ +cmd_dtc_cpp = $(CPP) $(cpp_flags) -D__DTS__ -x assembler-with-cpp -o $(dtc-tmp) $ ; \ + $(objtree)/scripts/dtc/dtc -O dtb -o $@ -b 0 $(DTC_FLAGS) $(dtc-tmp) + +$(obj)/%.dtb: $(src)/%.dtsp FORCE + $(call if_changed_dep,dtc_cpp) + # Bzip2 # --- -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x2000; /* CS0: NAND */
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
I'm a bit confused by this: what are the other two values in reg?
I see you've only added a binding for CS.
I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.
I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: add BCM2835 driver
Hi Stephen, On Thu, Jan 03 2013, Stephen Warren wrote: Add a very simple driver for the BCM2835 SoC, which is used in the Raspberry Pi board. Signed-off-by: Stephen Warren swar...@wwwdotorg.org Looks good, thanks -- pushed to mmc-next for 3.9. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] documentation: devicetree: Fix typo within Documentation/devicetree
On Mon, 14 Jan 2013 15:14:56 +0900, Masanari Iida standby2...@gmail.com wrote: Correct spelling typos within Documentation/devicetree Signed-off-by: Masanari Iida standby2...@gmail.com Applied, thanks. g. --- Documentation/devicetree/bindings/arm/atmel-aic.txt| 2 +- Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 2 +- Documentation/devicetree/bindings/arm/gic.txt | 4 ++-- Documentation/devicetree/bindings/arm/omap/omap.txt| 6 +++--- Documentation/devicetree/bindings/i2c/samsung-i2c.txt | 2 +- Documentation/devicetree/bindings/mips/cavium/dma-engine.txt | 2 +- Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt | 6 +++--- Documentation/devicetree/bindings/mmc/samsung-sdhci.txt| 2 +- Documentation/devicetree/bindings/powerpc/fsl/srio.txt | 4 ++-- Documentation/devicetree/bindings/regulator/tps62360-regulator.txt | 4 ++-- Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 2 +- Documentation/devicetree/bindings/watchdog/samsung-wdt.txt | 2 +- 12 files changed, 19 insertions(+), 19 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/atmel-aic.txt b/Documentation/devicetree/bindings/arm/atmel-aic.txt index 19078bf..ad03121 100644 --- a/Documentation/devicetree/bindings/arm/atmel-aic.txt +++ b/Documentation/devicetree/bindings/arm/atmel-aic.txt @@ -4,7 +4,7 @@ Required properties: - compatible: Should be atmel,chip-aic - interrupt-controller: Identifies the node as an interrupt controller. - interrupt-parent: For single AIC system, it is an empty property. -- #interrupt-cells: The number of cells to define the interrupts. It sould be 3. +- #interrupt-cells: The number of cells to define the interrupts. It should be 3. The first cell is the IRQ number (aka Peripheral IDentifier on datasheet). The second cell is used to specify flags: bits[3:0] trigger type and level flags: diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt index 6528e21..3fb457b 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -4,7 +4,7 @@ Exynos processors include support for multiple power domains which are used to gate power to one or more peripherals on the processor. Required Properties: -- compatiable: should be one of the following. +- compatible: should be one of the following. * samsung,exynos4210-pd - for exynos4210 type power domain. - reg: physical base address of the controller and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 62eb8df..3dfb0c0 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -42,7 +42,7 @@ Main node required properties: Optional - interrupts : Interrupt source of the parent interrupt controller on - secondary GICs, or VGIC maintainance interrupt on primary GIC (see + secondary GICs, or VGIC maintenance interrupt on primary GIC (see below). - cpu-offset : per-cpu offset within the distributor and cpu interface @@ -74,7 +74,7 @@ Required properties: virtual interface control register base and size. The 2nd additional region is the GIC virtual cpu interface register base and size. -- interrupts : VGIC maintainance interrupt. +- interrupts : VGIC maintenance interrupt. Example: diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index d0051a7..f8288ea 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -39,16 +39,16 @@ Boards: - OMAP3 Tobi with Overo : Commercial expansion board with daughter board compatible = ti,omap3-tobi, ti,omap3-overo, ti,omap3 -- OMAP4 SDP : Software Developement Board +- OMAP4 SDP : Software Development Board compatible = ti,omap4-sdp, ti,omap4430 - OMAP4 PandaBoard : Low cost community board compatible = ti,omap4-panda, ti,omap4430 -- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x +- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x compatible = ti,omap3-evm, ti,omap3 -- AM335X EVM : Software Developement Board for AM335x +- AM335X EVM : Software Development Board for AM335x compatible = ti,am335x-evm, ti,am33xx, ti,omap3 - AM335X Bone : Low cost community board diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt index b6cb5a1..ccdf9c9 100644 --- a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt +++
Re: [PATCH] cpsw: Add support to read cpu MAC address
On Fri, 11 Jan 2013 16:15:02 +0100, Michal Bachraty michal.bachr...@streamunlimited.com wrote: Signed-off-by: Michal Bachraty michal.bachr...@streamunlimited.com --- Documentation/devicetree/bindings/net/cpsw.txt | 10 +- arch/arm/boot/dts/am33xx.dtsi |5 +- drivers/net/ethernet/ti/cpsw.c | 121 +--- include/linux/platform_data/cpsw.h |8 ++ 4 files changed, 128 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index dcaabe9..432122c 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -4,7 +4,7 @@ TI SoC Ethernet Switch Controller Device Tree Bindings Required properties: - compatible : Should be ti,cpsw - reg: physical base address and size of the cpsw - registers map + registers map and mac-address cpu config registers - interrupts : property with a value describing the interrupt number - interrupt-parent : The parent interrupt controller @@ -25,17 +25,23 @@ Required properties: - slave_reg_ofs : Specifies slave register offset - sliver_reg_ofs : Specifies slave sliver register offset - phy_id : Specifies slave phy id -- mac-address: Specifies slave MAC address Optional properties: - ti,hwmods : Must be cpgmac0 - no_bd_ram : Must be 0 or 1 +- mac-address-source : Specifies source of MAC address (user-defined-mac, + cpu-id0-mac, cpu-id01-mac, random-mac). If not + specified, cpu-id0-mac is selected Drop the '-mac' suffix on the values. The property is already named mac-address-source, so I think it is already unambiguious from the context. :-) Otherwise the patch looks good to me, but I haven't gone over the code in fine detail. Acked-by: Grant Likely grant.lik...@secretlab.ca ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[GIT PULL] DeviceTree fixes for 3.8
Linus, Please pull these 2 small fixes for DT. The move to common dtb build rules went in through the DT tree, so I'm taking the fixes too. Rob The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://sources.calxeda.com/kernel/linux.git tags/dt-fixes-for-3.8 for you to fetch changes up to 1ab3681271c84b7f926be9ae3be1d769b7e933e9: ARM: dts: prevent *.dtb from always being rebuilt (2013-01-14 08:08:31 -0600) DeviceTree fixes for 3.8 2 fixes to prevent unconditional re-compile of dts files on arm and arm64. Stephen Warren (2): arm64: dts: prevent *.dtb from always being rebuilt ARM: dts: prevent *.dtb from always being rebuilt arch/arm/boot/dts/Makefile |1 + arch/arm64/boot/dts/Makefile |1 + 2 files changed, 2 insertions(+) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] hwmon: Driver for Maxim MAX6697 and compatibles
Hi Guenter,
Sorry for the late review, originally I planned to do a quick review
but apparently I am simply unable to do that. So here comes a complete
review. As usual, pick what you agree with and feel free to ignore the
rest :)
On Sun, 16 Dec 2012 21:33:09 -0800, Guenter Roeck wrote:
Add support for MAX6581, MAX6602, MAX6622, MAX6636, MAX6689, MAX6693,
MAX6694, MAX6697, MAX6698, and MAX6699 temperature sensors
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
v2:
- Add suppport for platform data and devicetree based chip initialization
- Drop S_IRUGOWU macro: s/S_IRUGOWU/S_IRUGO | S_IWUSR/
Documentation/devicetree/bindings/i2c/max6697.txt | 45 ++
Documentation/hwmon/max6697 | 57 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile|1 +
drivers/hwmon/max6697.c | 634
+
include/linux/platform_data/max6697.h | 25 +
6 files changed, 773 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/max6697.txt
create mode 100644 Documentation/hwmon/max6697
create mode 100644 drivers/hwmon/max6697.c
create mode 100644 include/linux/platform_data/max6697.h
diff --git a/Documentation/devicetree/bindings/i2c/max6697.txt
b/Documentation/devicetree/bindings/i2c/max6697.txt
new file mode 100644
index 000..3e867e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/max6697.txt
@@ -0,0 +1,45 @@
+max6697 properties
+
+Required properties:
+- compatible:
+ Should be one of
+ maxim,max6581
+ maxim,max6602
+ maxim,max6622
+ maxim,max6636
+ maxim,max6689
+ maxim,max6693
+ maxim,max6694
+ maxim,max6697
+ maxim,max6698
+ maxim,max6699
+- reg: I2C address
+
+Optional properties:
Your definition of optional is questionable. Setting _any_ of these
properties will cause _all_ others to be considered as 0 and the chip
will be reprogrammed with these settings. I'd say this is unexpected and
confusing. I'd expect struct max6697_platform_data to be able to store
don't change for every setting, so that only the properties actually
provided are written to the chip.
If you really don't want to do that, then you should make it prominently
visible both here and in max6697.h that one should either set all
properties or none. Beware though that this may still cause trouble if
you ever have to add one property to the set in the future.
+- smbus-timeout-disable
+ Set to enable SMBus timeout
+- extended-range-enable
+ Only valid for MAX6581. Set to enable extended temperature range.
+- alert-mask
+ Alert bit mask. Alert disabled for bits set.
+- over-temperature-mask
+ Over temperature bit mask. Over temperature reporting disabled for
+ bits set.
+- resistance-cancellation
+ Boolean for all chips other than MAX6581. Enabled if set.
+ For MAX6581, resistance cancellation enabled for all channels if
+ specified as boolean, otherwise as per bit mask specified.
+- transistor-ideality
+ For MAX6581 only. Two values; first is bit mask, second is ideality
+ select value as per MAX6581 data sheet.
I'm not familiar with OF properties... Is there any standard for the
properties above? If not, and other drivers implement similar
properties, did you make sure to follow existing common practice?
+
+Example:
+
+temp-sensor@1a {
+ compatible = maxim,max6697;
+ reg = 0x1a;
+ smbus-timeout-disable;
+ resistance-cancellation;
+ alert-mask = 0xff;
+ over-temperature-mask = 0xff;
+};
For a 7-channel chip, mask values of 0xff make little sense IMHO.
diff --git a/Documentation/hwmon/max6697 b/Documentation/hwmon/max6697
new file mode 100644
index 000..35fc2e9
--- /dev/null
+++ b/Documentation/hwmon/max6697
@@ -0,0 +1,57 @@
+Kernel driver max6697
+=
+
+Supported chips:
+ * Maxim MAX6581
+Prefix: 'max6581'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf
+ * Maxim MAX6602
+Prefix: 'max6602'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf
+ * Maxim MAX6622
+Prefix: 'max6622'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf
+ * Maxim MAX6636
+Prefix: 'max6636'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf
+ * Maxim MAX6689
+Prefix: 'max6689'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf
+ * Maxim MAX6693
+Prefix: 'max6693'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf
+ * Maxim MAX6694
+Prefix: 'max6694'
+Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf
+ * Maxim MAX6697
+Prefix: 'max6697'
+Datasheet:
Re: Early kernel hang with big DTB appended
On Fri, 11 Jan 2013, Sascha Hauer wrote: On Thu, Jan 03, 2013 at 04:55:00PM +0100, Tomasz Figa wrote: Hi, I'm observing strange behavior when booting 3.8-rc1 and -rc2 with appended DTB. The kernel hangs very early when the DTB is bigger than some threshold somewhere around 24 KiB. With fullest possible low level UART debugging (and printk patched to use printascii) I'm receiving following output: Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0xa00 Linux version 3.8.0-rc1-00073-gdf6efca-dirty (t.figa@amdc1227) (gcc version 4.5.2 (Gentoo 4.5.2 p1.2, pie-0.4.5) ) #2 SMP PREEMPT Thu Jan 3 15:37:35 CET 2013 CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache I tested on two Exynos-based boards (exynos4210-trats and one internal exynos4412-based board) and same happens on both. Do you have any ideas? Another thing besides the things already mentioned is that the dtb may not cross a 1MiB boundary. The Kernel uses a single 1Mib section (aligned to 1Mib) to initially map the dtb. Once you cross that boundary parts of the dtb won't be accessible for the Kernel anymore. Crap. You're right. This patch should fix this issue. @Tomasz: please could you confirm this fixes your initial problem? diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 4eee351f46..61fcb18c7e 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -246,6 +246,7 @@ __create_page_tables: /* * Then map boot params address in r2 if specified. +* We map 2 sections in case the ATAGs/DTB crosses a section boundary. */ mov r0, r2, lsr #SECTION_SHIFT movsr0, r0, lsl #SECTION_SHIFT @@ -253,6 +254,8 @@ __create_page_tables: addne r3, r3, #PAGE_OFFSET addne r3, r4, r3, lsr #(SECTION_SHIFT - PMD_ORDER) orrne r6, r7, r0 + strne r6, [r3], #1 PMD_ORDER + addne r6, r6, #1 SECTION_SHIFT strne r6, [r3] #ifdef CONFIG_DEBUG_LL ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation
On Mon, Jan 14, 2013 at 08:16:44AM -0800, Greg Kroah-Hartman wrote:
On Mon, Jan 14, 2013 at 04:49:59PM +0100, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 10:23:52AM +0100, Thierry Reding wrote:
On Wed, Jan 09, 2013 at 01:19:39AM -0800, Dmitry Torokhov wrote:
On Wed, Jan 09, 2013 at 08:07:45AM +0100, Thierry Reding wrote:
On Sun, Jan 06, 2013 at 11:57:48AM -0800, Dmitry Torokhov wrote:
On Sun, Jan 06, 2013 at 08:27:39PM +0100, Thierry Reding wrote:
On Sat, Jan 05, 2013 at 12:06:58AM -0800, Dmitry Torokhov wrote:
On Sat, Jan 05, 2013 at 01:15:08PM +0530, Laxman Dewangan wrote:
[...]
@@ -735,25 +738,16 @@ static int tegra_kbc_probe(struct
platform_device *pdev)
spin_lock_init(kbc-lock);
setup_timer(kbc-timer, tegra_kbc_keypress_timer,
(unsigned long)kbc);
- res = request_mem_region(res-start,
resource_size(res), pdev-name);
- if (!res) {
- dev_err(pdev-dev, failed to request I/O
memory\n);
- err = -EBUSY;
- goto err_free_mem;
- }
-
- kbc-mmio = ioremap(res-start, resource_size(res));
+ kbc-mmio = devm_request_and_ioremap(pdev-dev, res);
if (!kbc-mmio) {
- dev_err(pdev-dev, failed to remap I/O
memory\n);
- err = -ENXIO;
- goto err_free_mem_region;
+ dev_err(pdev-dev, Cannot request
memregion/iomap address\n);
+ return -EADDRNOTAVAIL;
Erm, no, -EBUSY please.
EADDRNOTAVAIL is the canonical error for
devm_request_and_ioremap()
failure. The kerneldoc comment in lib/devres.c even gives a short
example that uses this error code.
I am sorry, but I do not consider a function that was added a little
over a year ago as a canon. If you look at the uses of
EADDRNOTAVAIL it
is used predominantly in networking code to indicate that attempted
_network_ address is not available.
EBUSY might be misleading, though. devm_request_and_ioremap() can fail
in both the request_mem_region() and ioremap() calls. Furthermore it'd
be good to settle on a consistent error-code instead of doing it
differently depending on subsystem and/or driver. Currently the
various
error codes used are:
EBUSY, EADDRNOTAVAIL, ENXIO, ENOMEM, ENODEV, ENOENT, EINVAL,
EIO, EFAULT, EADDRINUSE
Also if we can settle on one error code we should follow up with a
patch
to make it consistent across the tree and also update that kerneldoc
comment. I volunteer to do that if nobody else steps up. I'm also
Cc'ing
Wolfram (the original author), maybe he has some thoughts on this.
If you going to change all drivers make devm_request_and_ioremap()
return ERR_PTR()-encoded errors and then we can differentiate what
part of it failed.
Yeah, that thought also crossed my mind. I'll give other people some
time to comment before hurling myself into preparing patches.
I've prepared a patch that changes devm_request_and_ioremap() to return
ERR_PTR()-encoded errors and adjusts all callers. As you can imagine it
is a bit on the huge side. scripts/get_maintainer.pl lists 156 people
and mailing lists. I've gone through the list, and as far as I can tell
everyone on that list is actually affected by the patch, so there's not
much potential for tuning it down.
There is also the issue of whose tree this should go into. Unfortunately
the patch can't be broken down into smaller chunks because it changes
how the devm_request_and_ioremap() function's return value is handled in
an incompatible way, so it won't be possible to gradually phase this in.
Furthermore I can imagine that until the end of the release cycle new
code may be added on which the same transformations need to be done. I
have a semantic patch to do the bulk of the work, but quite a bit of
coordination will be required.
I'm adding Arnd and Greg on Cc, maybe they can advise on how best to
handle this kind of patch.
You should provide a wrapper function that does the correct return
value, convert drivers over to it, and then, when everyone is changed,
drop the old call. To change 156 different drivers all at once, in a
way that is not detectable by the compiler breaking the build, is not a
good thing to do at all.
By doing it in this manner, it will take longer, but you can push the
patches through the different maintainer's trees. If they are slow,
I'll be glad to take the remaining patches in my driver-core tree to do
the final bits.
It certainly sounds like a less complicated way to do it. But it also
involves adding a function with a made up
Re: [PATCH] usb: phy: samsung: Add support to set pmu isolation
Vivek,
Sorry for being so absent from these reviews. I'll try to look over a
few patches today, but please don't hold up anything on account of my
reviews. I'm definitely a bit of an interested bystander in USB land.
;)
In general things look pretty good here. :) One last comment below...
On Fri, Jan 11, 2013 at 12:08 AM, Vivek Gautam
gautam.vi...@samsung.com wrote: +static int
samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
+{
+ struct device_node *usbphy_sys;
+
+ /* Getting node for system controller interface for usb-phy */
+ usbphy_sys = of_get_child_by_name(sphy-dev-of_node, usbphy-sys);
+ if (!usbphy_sys)
+ dev_warn(sphy-dev, No sys-controller interface for
usb-phy\n);
Seems like you ought to return with an error here. Calling of_iomap()
with a NULL value seems undesirable.
+
+ sphy-pmuregs = of_iomap(usbphy_sys, 0);
+
+ of_node_put(usbphy_sys);
+
+ if (sphy-pmuregs == NULL) {
+ dev_err(sphy-dev, Can't get usb-phy pmu control
register\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/*
+ * Set isolation here for phy.
+ * Here 'on = true' would mean USB PHY block is isolated, hence
+ * de-activated and vice-versa.
+ */
Thank you very much for this comment. :) This explains one of the
confusions I had earlier...
Once you fix the one error condition above you can add my
Reviewed-by. Thanks!
-Doug
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation
On Monday 14 January 2013, Thierry Reding wrote: It certainly sounds like a less complicated way to do it. But it also involves adding a function with a made up name and drop a function with a perfectly good name instead. I wouldn't even know what name to choose for the new API. How about devm_ioremap_resource()? Sounds equally fitting, and is shorter. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8 5/5] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
On Jan 15, 2013 2:06 AM, Tony Lindgren t...@atomide.com wrote:
* Ezequiel Garcia elezegar...@gmail.com [121223 13:49]:
On Fri, Dec 14, 2012 at 7:36 AM, Daniel Mack zon...@gmail.com wrote:
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupts = 100;
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x2000; /* CS0: NAND
*/
+
+ nand@0,0 {
+ reg = 0 0 0; /* CS0, offset 0 */
I'm a bit confused by this: what are the other two values in reg?
I see you've only added a binding for CS.
I've extended a bit on your work and added a binding to enable OneNAND
device on my IGEP board.
I might send some patches in case anyone wants to give it a try.
Daniel, should this be updated to just pass the CS?
No, as Rob pointed out earlier in a thread about this topic, the 'ranges'
feature will help doing the math for the offset calculation eventually, so
we need to pass all three values.
Regards,
Daniel
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/4] usb: phy: samsung: Add host phy support to samsung-phy driver
Vivek, On Mon, Jan 14, 2013 at 12:06 AM, Vivek Gautam gautamvivek1...@gmail.com wrote: Is it fine if we don't use macro for SHIFT, earlier code also doesn't use it. Can we just do like this .. #define HOST_CTRL0_FSEL_MASK (0x7 16) #define HOST_CTRL0_FSEL_CLKSEL_50M(0x7 16) #define HOST_CTRL0_FSEL_CLKSEL_24M(0x5 16) #define HOST_CTRL0_FSEL_CLKSEL_20M(0x4 16) #define HOST_CTRL0_FSEL_CLKSEL_19200K (0x3 16) #define HOST_CTRL0_FSEL_CLKSEL_12M(0x2 16) #define HOST_CTRL0_FSEL_CLKSEL_10M(0x1 16) #define HOST_CTRL0_FSEL_CLKSEL_9600K (0x0 16) I don't have a problem with just putting the 16 there... Actually missed one thing here, this HOST_CTRL0_FSEL_CLKSEL_XX is being used by HOST/OTG blocks to prepare reference clock, that's the reason we kept #define HOST_CTRL0_FSEL(_x) ((_x) 16) and #define OTG_SYS_FSEL(_x) ((_x) 4) where (_x) is the reference clock returned from samsung_usbphy_get_refclk_freq(). I feel like samsung_usbphy_get_refclk_freq() is supposed to be returning an already shifted value. ...at least that's how it appears to work with existing code. Why does it feel like that? ...because with existing code we have: #define PHYCLK_CLKSEL_MASK (0x3 0) #define PHYCLK_CLKSEL_48M (0x0 0) #define PHYCLK_CLKSEL_12M (0x2 0) #define PHYCLK_CLKSEL_24M (0x3 0) Those #defines are what are returned by samsung_usbphy_get_refclk_freq(). The fact that the 0 is there implies (to me) that the existing function would return shifted values if it were applicable. For exynos you are having the same function return things like: #define FSEL_CLKSEL_50M (0x7) #define FSEL_CLKSEL_24M (0x5) #define FSEL_CLKSEL_20M (0x4) ...to me that means that the exynos code is returning unshifted values. If you say that samsung_usbphy_get_refclk_freq() is in charge of returning shifted values then you no longer need the HOST_CTRL0_FSEL() macro. In any case, I will defer to whatever Felipe thinks is best here (if he has an opinion on it). I am only pointing out that the exynos code and existing code seem to be specifying things differently. That's weird to me. so we can change this to something like case 10 * MHZ: refclk_freq = FSEL_CLKSEL_10M; break; and so on. will this be fine ? Seems good to me. -Doug ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/8] sh-pfc: Add OF support
On Sat, Jan 12, 2013 at 06:18:54PM +0100, Guennadi Liakhovetski wrote: Hi Laurent On Wed, 9 Jan 2013, Laurent Pinchart wrote: Support device instantiation through the device tree. The compatible property is used to select the SoC pinmux information. Set the gpio_chip device field to the PFC device to enable automatic GPIO OF support. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Cc: devicetree-discuss@lists.ozlabs.org This whole pinctrl mega-series is a very welcome improvement to the sh-/r-mobile GPIO framework, and is very well done IMHO! But, unfortunately, as discussed with you privately yesterday, there is still a problem with pinctrl DT support on sh73a0, which will, probably, enforce an update to one or several of patches from this lot. To explain to other readers, on sh73a0 pin numbers are not contiguous, they are sparse. When pins are referred to from C code, macro names are used, which are then correctly decoded to respective positions in pin descriptor tables. Whereas with DT, pins are referred to from .dts files using their physical numbers, which then refer to either wrong or missing entries in those tables. I do not know where this problem should be solved best - either in descriptor tables, or in DT handling code, so, I don't know which patches would be affected. Don't think you'll want to keep the one-to-one index-to-pin mapping by also making pin-descriptor arrays sparse, so, so far I only see one possibility to fix this - by using the .enum_id field from struct sh_pfc_pin instead of just the index - both in C and in DT case, and those .enum_id values will have to provide physical pin numbers instead of plane indices. That way you'd have to update at least drivers/pinctrl/sh-pfc/pfc-sh73a0.c and the sh_pfc_map_gpios() function in drivers/pinctrl/sh-pfc/pinctrl.c. Anyway, I'm sure you'll find a suitable solution of this problem and for now I'll let Simon decide which patches he wants to apply and which ones he'd prefer to hold back;-) Actually, I'd appreciate some guidance from Laurent on this. It seems that the problems you raise go quite far back into the mega-series. I was intending to send pull requests for the following branches soon. But I am now concerned that at least the sh73a0 patches may need reworking. pfc2: (based on a merge of sh-soc2 and pfc) sh-pfc: Add shx3 pinmux support sh-pfc: Add sh7786 pinmux support sh-pfc: Add sh7785 pinmux support sh-pfc: Add sh7757 pinmux support sh-pfc: Add sh7734 pinmux support sh-pfc: Add sh7724 pinmux support sh-pfc: Add sh7723 pinmux support sh-pfc: Add sh7722 pinmux support sh-pfc: Add sh7720 pinmux support sh-pfc: Add sh7269 pinmux support sh-pfc: Add sh7264 pinmux support sh-pfc: Add sh7203 pinmux support sh-pfc: Add sh73a0 pinmux support sh-pfc: Add sh7372 pinmux support sh-pfc: Add r8a7779 pinmux support sh-pfc: Add r8a7740 pinmux support sh-pfc: Support pinmux info in driver data instead of platform data sh-pfc: Move driver from drivers/sh/ to drivers/pinctrl/ sh-pfc: Remove unused resource and num_resources platform data fields sh-pfc: Remove platform device registration sh-soc2: (based on pfc) sh: shx3: Register PFC platform device sh: sh7786: Register PFC platform device sh: sh7785: Register PFC platform device sh: sh7757: Register PFC platform device sh: sh7734: Register PFC platform device sh: sh7724: Register PFC platform device sh: sh7723: Register PFC platform device sh: sh7722: Register PFC platform device sh: sh7720: Register PFC platform device sh: sh7269: Register PFC platform device sh: sh7264: Register PFC platform device sh: sh7203: Register PFC platform device sh: Add PFC platform device registration helper function soc: (based on sh-soc) ARM: shmobile: sh73a0: Add pin control resources ARM: shmobile: sh7372: Add pin control resources ARM: shmobile: r8a7740: Add pin control resources ARM: shmobile: sh73a0: Register PFC platform device ARM: shmobile: sh7372: Register PFC platform device ARM: shmobile: r8a7779: Register PFC platform device ARM: shmobile: r8a7740: Register PFC platform device ARM: shmobile: Select PINCTRL ARM: shmobile: add function declarations for sh7372 DT helper functions ARM: sh7372: fix cache clean / invalidate order ARM: sh7372: add clock lookup entries for DT-based devices ARM: mach-shmobile: sh73a0 external IRQ wake update ARM: shmobile: sh73a0: fixup div4_clks bitmap ARM: shmobile: r8a7740: add TMU timer support ARM: shmobile: Remove duplicate inclusion of dma-mapping.h in setup-r8a7740.c pfc: (based on sh-soc) sh-pfc: Support passing resources through platform device sh-pfc: Split platform device and platform driver registration sh-pfc: Use sh_pfc_ namespace prefix through the whole driver sh-pfc: Sort headers alphabetically sh-pfc: Remove check for impossible error condition sh-pfc: Let the compiler decide whether to inline functions sh-pfc: Use devm_ioremap_nocache() sh-pfc: Use
[PATCH V2] i2c: add bcm2835 driver
This implements a very basic I2C host driver for the BCM2835 SoC. Missing
features so far are:
* 10-bit addressing.
* DMA.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
v2:
* Implemented clock divider configuration based on desired bus rate.
* Make use of module_platform_driver().
* Removed use of devinit.
---
.../devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | 20 ++
drivers/i2c/busses/Kconfig | 12 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-bcm2835.c | 346
4 files changed, 379 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
create mode 100644 drivers/i2c/busses/i2c-bcm2835.c
diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
new file mode 100644
index 000..e9de375
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt
@@ -0,0 +1,20 @@
+Broadcom BCM2835 I2C controller
+
+Required properties:
+- compatible : Should be brcm,bcm2835-i2c.
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks : The clock feeding the I2C controller.
+
+Recommended properties:
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Example:
+
+i2c@20205000 {
+ compatible = brcm,bcm2835-i2c;
+ reg = 0x7e205000 0x1000;
+ interrupts = 2 21;
+ clocks = clk_i2c;
+ clock-frequency = 10;
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index bdca511..5aab774 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -319,6 +319,18 @@ config I2C_AU1550
This driver can also be built as a module. If so, the module
will be called i2c-au1550.
+config I2C_BCM2835
+ tristate Broadcom BCM2835 I2C controller
+ depends on ARCH_BCM2835
+ help
+ If you say yes to this option, support will be included for the
+ BCM2835 I2C controller.
+
+ If you don't know what to do here, say N.
+
+ This support is also available as a module. If so, the module
+ will be called i2c-bcm2835.
+
config I2C_BLACKFIN_TWI
tristate Blackfin TWI I2C support
depends on BLACKFIN
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 6181f3f..a52a891 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
# Embedded system I2C/SMBus host controller drivers
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
+obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
new file mode 100644
index 000..22a29de
--- /dev/null
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -0,0 +1,346 @@
+/*
+ * BCM2835 master mode driver
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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/clk.h
+#include linux/completion.h
+#include linux/err.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#define BCM2835_I2C_C 0x0
+#define BCM2835_I2C_S 0x4
+#define BCM2835_I2C_DLEN 0x8
+#define BCM2835_I2C_A 0xc
+#define BCM2835_I2C_FIFO 0x10
+#define BCM2835_I2C_DIV0x14
+#define BCM2835_I2C_DEL0x18
+#define BCM2835_I2C_CLKT 0x1c
+
+#define BCM2835_I2C_C_READ BIT(0)
+#define BCM2835_I2C_C_CLEARBIT(4) /* bits 4 and 5 both clear */
+#define BCM2835_I2C_C_ST BIT(7)
+#define BCM2835_I2C_C_INTD BIT(8)
+#define BCM2835_I2C_C_INTT BIT(9)
+#define BCM2835_I2C_C_INTR BIT(10)
+#define BCM2835_I2C_C_I2CENBIT(15)
+
+#define BCM2835_I2C_S_TA BIT(0)
+#define BCM2835_I2C_S_DONE BIT(1)
+#define BCM2835_I2C_S_TXW BIT(2)
+#define BCM2835_I2C_S_RXR BIT(3)
+#define BCM2835_I2C_S_TXD BIT(4)
+#define BCM2835_I2C_S_RXD BIT(5)
+#define BCM2835_I2C_S_TXE BIT(6)
+#define BCM2835_I2C_S_RXF BIT(7)
+#define BCM2835_I2C_S_ERR BIT(8)
+#define BCM2835_I2C_S_CLKT BIT(9)
+#define BCM2835_I2C_S_LEN BIT(10) /* Fake bit for SW error reporting */
+
+#define BCM2835_I2C_TIMEOUT
[PATCH] ARM: bcm2835: fix clock node aliasing in device tree
Both clock nodes in the current device tree are named clock and hence
end up being the same node. Rename the nodes to different names to avoid
this. In fact, fixed-clock uses the node name as the clock name, so name
the nodes after the clock they represent. Move the clocks into a
clocks sub-node to group them and avoid any possible naming conflicts
with other nodes also named after the device type.
Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
arch/arm/boot/dts/bcm2835.dtsi | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index c69a591..4bf2a87 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -89,15 +89,23 @@
};
};
- clk_i2c: clock {
- compatible = fixed-clock;
- #clock-cells = 0;
- clock-frequency = 15000;
- };
+ clocks {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
- clk_mmc: clock {
- compatible = fixed-clock;
- #clock-cells = 0;
- clock-frequency = 1;
+ clk_mmc: mmc {
+ compatible = fixed-clock;
+ reg = 0;
+ #clock-cells = 0;
+ clock-frequency = 1;
+ };
+
+ clk_i2c: i2c {
+ compatible = fixed-clock;
+ reg = 1;
+ #clock-cells = 0;
+ clock-frequency = 15000;
+ };
};
};
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] usb: phy: samsung: Add support to set pmu isolation
Hi Doug,
On Tue, Jan 15, 2013 at 3:41 AM, Doug Anderson diand...@chromium.org wrote:
Vivek,
Sorry for being so absent from these reviews. I'll try to look over a
few patches today, but please don't hold up anything on account of my
reviews. I'm definitely a bit of an interested bystander in USB land.
;)
In general things look pretty good here. :) One last comment below...
On Fri, Jan 11, 2013 at 12:08 AM, Vivek Gautam
gautam.vi...@samsung.com wrote: +static int
samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
+{
+ struct device_node *usbphy_sys;
+
+ /* Getting node for system controller interface for usb-phy */
+ usbphy_sys = of_get_child_by_name(sphy-dev-of_node, usbphy-sys);
+ if (!usbphy_sys)
+ dev_warn(sphy-dev, No sys-controller interface for
usb-phy\n);
Seems like you ought to return with an error here. Calling of_iomap()
with a NULL value seems undesirable.
Yeah, true. This should have been returning error value alongwith dev_err().
+
+ sphy-pmuregs = of_iomap(usbphy_sys, 0);
+
+ of_node_put(usbphy_sys);
+
+ if (sphy-pmuregs == NULL) {
+ dev_err(sphy-dev, Can't get usb-phy pmu control
register\n);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/*
+ * Set isolation here for phy.
+ * Here 'on = true' would mean USB PHY block is isolated, hence
+ * de-activated and vice-versa.
+ */
Thank you very much for this comment. :) This explains one of the
confusions I had earlier...
Your welcome :-)
Once you fix the one error condition above you can add my
Reviewed-by. Thanks!
Sure, thanks !!
--
Thanks Regards
Vivek
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] hwmon: Driver for Maxim MAX6697 and compatibles
On Mon, Jan 14, 2013 at 10:24:04PM +0100, Jean Delvare wrote:
Hi Guenter,
Sorry for the late review, originally I planned to do a quick review
but apparently I am simply unable to do that. So here comes a complete
review. As usual, pick what you agree with and feel free to ignore the
rest :)
Hi Jean,
as always an excellent and thorough review.
Couple of comments inline.
On Sun, 16 Dec 2012 21:33:09 -0800, Guenter Roeck wrote:
Add support for MAX6581, MAX6602, MAX6622, MAX6636, MAX6689, MAX6693,
MAX6694, MAX6697, MAX6698, and MAX6699 temperature sensors
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
v2:
- Add suppport for platform data and devicetree based chip initialization
- Drop S_IRUGOWU macro: s/S_IRUGOWU/S_IRUGO | S_IWUSR/
Documentation/devicetree/bindings/i2c/max6697.txt | 45 ++
Documentation/hwmon/max6697 | 57 ++
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile|1 +
drivers/hwmon/max6697.c | 634
+
include/linux/platform_data/max6697.h | 25 +
6 files changed, 773 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/max6697.txt
create mode 100644 Documentation/hwmon/max6697
create mode 100644 drivers/hwmon/max6697.c
create mode 100644 include/linux/platform_data/max6697.h
diff --git a/Documentation/devicetree/bindings/i2c/max6697.txt
b/Documentation/devicetree/bindings/i2c/max6697.txt
new file mode 100644
index 000..3e867e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/max6697.txt
@@ -0,0 +1,45 @@
+max6697 properties
+
+Required properties:
+- compatible:
+ Should be one of
+ maxim,max6581
+ maxim,max6602
+ maxim,max6622
+ maxim,max6636
+ maxim,max6689
+ maxim,max6693
+ maxim,max6694
+ maxim,max6697
+ maxim,max6698
+ maxim,max6699
+- reg: I2C address
+
+Optional properties:
Your definition of optional is questionable. Setting _any_ of these
properties will cause _all_ others to be considered as 0 and the chip
will be reprogrammed with these settings. I'd say this is unexpected and
Actually, not just any, but the values have to be specified if OF data is
present and a non-default configuration is wanted. I clarified that in the
text.
confusing. I'd expect struct max6697_platform_data to be able to store
don't change for every setting, so that only the properties actually
provided are written to the chip.
If you really don't want to do that, then you should make it prominently
visible both here and in max6697.h that one should either set all
properties or none. Beware though that this may still cause trouble if
you ever have to add one property to the set in the future.
I tried to find a better wording. I do want to set all values, so that part is
on purpose.
+- smbus-timeout-disable
+ Set to enable SMBus timeout
s/enable/disable/
+- extended-range-enable
+ Only valid for MAX6581. Set to enable extended temperature range.
+- alert-mask
+ Alert bit mask. Alert disabled for bits set.
+- over-temperature-mask
+ Over temperature bit mask. Over temperature reporting disabled for
+ bits set.
+- resistance-cancellation
+ Boolean for all chips other than MAX6581. Enabled if set.
+ For MAX6581, resistance cancellation enabled for all channels if
+ specified as boolean, otherwise as per bit mask specified.
+- transistor-ideality
+ For MAX6581 only. Two values; first is bit mask, second is ideality
+ select value as per MAX6581 data sheet.
I'm not familiar with OF properties... Is there any standard for the
properties above? If not, and other drivers implement similar
properties, did you make sure to follow existing common practice?
No, not for the optional properties; I did not find anything for those.
I had tried to submit a generic means to configure i2c chips via OF,
but that was rejected even though a similar approach is used for some
PHY chips.
[ ... ]
+
+static ssize_t show_temp11(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ int nr = to_sensor_dev_attr_2(devattr)-nr;
+ int index = to_sensor_dev_attr_2(devattr)-index;
+ struct max6697_data *data = max6697_update_device(dev);
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ return sprintf(buf, %d\n,
+ ((data-temp[nr][index] 3) |
+ (data-temp[nr][index + 1] 5)) * 125);
I can't see this code dealing properly with the negative temperature
values supported by the MAX6581, nor with its extended format... nor
with its normal format BTW, as it turns out to be completely different
from the other chips.
Actually, the data sheet is wrong
[PATCH v7] usb: phy: samsung: Add support to set pmu isolation
Adding support to parse device node data in order to get
required properties to set pmu isolation for usb-phy.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Changes from v6:
- Returning error code in samsung_usbphy_parse_dt() when
'usbphy-sys' sub-node is not present and thereby putting up
dev_err() instead of dev_warn()
.../devicetree/bindings/usb/samsung-usbphy.txt | 36 +
drivers/usb/phy/samsung-usbphy.c | 163 +---
2 files changed, 177 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..22d06cf 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -9,3 +9,39 @@ Required properties:
- compatible : should be samsung,exynos4210-usbphy
- reg : base physical address of the phy registers and length of memory mapped
region.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- ranges: allows valid translation between child's address space and parent's
+ address space.
+
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+ interface for usb-phy. It should provide the following information required
by
+ usb-phy controller to control phy.
+ - reg : base physical address of PHY_CONTROL registers.
+ The size of this register is the total sum of size of all PHY_CONTROL
+ registers that the SoC has. For example, the size will be
+ '0x4' in case we have only one PHY_CONTROL register (e.g.
+ OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+ and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+ USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+ and so on.
+
+Example:
+ - Exynos4210
+
+ usbphy@125B {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = samsung,exynos4210-usbphy;
+ reg = 0x125B 0x100;
+ ranges;
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = 0x10020704 0x8;
+ };
+ };
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 5c5e1bb5..30aebb5 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -24,6 +24,7 @@
#include linux/err.h
#include linux/io.h
#include linux/of.h
+#include linux/of_address.h
#include linux/usb/otg.h
#include linux/platform_data/samsung-usbphy.h
@@ -60,20 +61,46 @@
#define MHZ (1000*1000)
#endif
+#define S3C64XX_USBPHY_ENABLE (0x1 16)
+#define EXYNOS_USBPHY_ENABLE (0x1 0)
+
enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
};
/*
+ * struct samsung_usbphy_drvdata - driver data for various SoC variants
+ * @cpu_type: machine identifier
+ * @devphy_en_mask: device phy enable mask for PHY CONTROL register
+ * @devphy_reg_offset: offset to DEVICE PHY CONTROL register from
+ *mapped address of system controller.
+ *
+ * Here we have a separate mask for device type phy.
+ * Having different masks for host and device type phy helps
+ * in setting independent masks in case of SoCs like S5PV210,
+ * in which PHY0 and PHY1 enable bits belong to same register
+ * placed at position 0 and 1 respectively.
+ * Although for newer SoCs like exynos these bits belong to
+ * different registers altogether placed at position 0.
+ */
+struct samsung_usbphy_drvdata {
+ int cpu_type;
+ int devphy_en_mask;
+ u32 devphy_reg_offset;
+};
+
+/*
* struct samsung_usbphy - transceiver driver state
* @phy: transceiver structure
* @plat: platform data
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
- * @regs: usb phy register memory base
+ * @regs: usb phy controller registers memory base
+ * @pmuregs: USB device PHY_CONTROL register memory base
* @ref_clk_freq: reference clock frequency selection
- * @cpu_type: machine identifier
+ * @drv_data: driver data available for different SoCs
+ * @lock: lock for phy operations
*/
struct samsung_usbphy {
struct usb_phy phy;
@@ -81,12 +108,66 @@ struct samsung_usbphy {
struct device *dev;
struct clk *clk;
void __iomem*regs;
+ void __iomem*pmuregs;
int ref_clk_freq;
- int cpu_type;
+ const struct samsung_usbphy_drvdata *drv_data;
+ spinlock_t
[PATCH v2 1/4] ARM i.MX6: use reserved bit for mxs phy clock gate
For mxs-phy user i.mx6q, the PHY's clock is controlled by hardware automatically, the software only needs to enable it at probe, disable it at remove. During the runtime, we don't need to control it. So for the usbphy clk policy: - Keep refcount for usbphy as clk framework needs to know if it is off or on. - Use reserved bit, in that case, clk_enable/disable will only update refcount, but without any hardware effects. Signed-off-by: Peter Chen peter.c...@freescale.com --- Changes for v2: - Use reserved bit for usb phy clk control arch/arm/mach-imx/clk-imx6q.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c index 7f2c10c..85dcc89 100644 --- a/arch/arm/mach-imx/clk-imx6q.c +++ b/arch/arm/mach-imx/clk-imx6q.c @@ -208,8 +208,14 @@ int __init mx6q_clocks_init(void) clk[pll7_usb_host] = imx_clk_pllv3(IMX_PLLV3_USB, pll7_usb_host,osc, base + 0x20, 0x3); clk[pll8_mlb] = imx_clk_pllv3(IMX_PLLV3_MLB, pll8_mlb, osc, base + 0xd0, 0x0); - clk[usbphy1] = imx_clk_gate(usbphy1, pll3_usb_otg, base + 0x10, 6); - clk[usbphy2] = imx_clk_gate(usbphy2, pll7_usb_host, base + 0x20, 6); + /* +* Bit 20 is the reserved and read-only bit, we do this only for: +* - Do nothing for usbphy clk_enable/disable +* - Keep refcount when do usbphy clk_enable/disable, in that case, +* the clk framework can know the USB phy clk is on or off +*/ + clk[usbphy1] = imx_clk_gate(usbphy1, pll3_usb_otg, base + 0x10, 20); + clk[usbphy2] = imx_clk_gate(usbphy2, pll7_usb_host, base + 0x20, 20); clk[sata_ref] = imx_clk_fixed_factor(sata_ref, pll6_enet, 1, 5); clk[pcie_ref] = imx_clk_fixed_factor(pcie_ref, pll6_enet, 1, 4); -- 1.7.0.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 2/4] usb: mxs-phy: change clock usage for i.mx6q
For mxs-phy user i.mx6q, the PHY's clock is controlled by
hardware automatically, the software only needs to enable it
at probe, disable it at remove. But other mxs-phy users need
to control that clock runtime, so we hardcode clk on/off,
and give a reserved bit for clk on/off at clk code for i.mx6q.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
Changes for v2:
- Only control gate bit for phy clk control
- Only open the gate at probe, and close the gate at remove
Documentation/devicetree/bindings/usb/mxs-phy.txt |2 +
arch/arm/boot/dts/imx6q.dtsi |2 +
drivers/usb/otg/mxs-phy.c | 61 +
3 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt
b/Documentation/devicetree/bindings/usb/mxs-phy.txt
index 5835b27..384e700 100644
--- a/Documentation/devicetree/bindings/usb/mxs-phy.txt
+++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
@@ -4,10 +4,12 @@ Required properties:
- compatible: Should be fsl,imx23-usbphy
- reg: Should contain registers location and length
- interrupts: Should contain phy interrupt
+- The reg offset for PHY clock at anatop
Example:
usbphy1: usbphy@020c9000 {
compatible = fsl,imx6q-usbphy, fsl,imx23-usbphy;
reg = 0x020c9000 0x1000;
interrupts = 0 44 0x04;
+ anatop-phy-reg-offset = 0x10;
};
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index d6265ca..1517e93 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -519,6 +519,7 @@
reg = 0x020c9000 0x1000;
interrupts = 0 44 0x04;
clocks = clks 182;
+ anatop-phy-reg-offset = 0x10;
};
usbphy2: usbphy@020ca000 {
@@ -526,6 +527,7 @@
reg = 0x020ca000 0x1000;
interrupts = 0 45 0x04;
clocks = clks 183;
+ anatop-phy-reg-offset = 0x20;
};
snvs@020cc000 {
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index 7630272..49727dd 100644
--- a/drivers/usb/otg/mxs-phy.c
+++ b/drivers/usb/otg/mxs-phy.c
@@ -20,6 +20,9 @@
#include linux/delay.h
#include linux/err.h
#include linux/io.h
+#include linux/of.h
+#include linux/regmap.h
+#include linux/mfd/syscon.h
#define DRIVER_NAME mxs_phy
@@ -34,6 +37,11 @@
#define BM_USBPHY_CTRL_ENUTMILEVEL2BIT(14)
#define BM_USBPHY_CTRL_ENHOSTDISCONDETECT BIT(1)
+#define CTRL_SET 0x4
+#define CTRL_CLR 0x8
+
+#define BM_ANADIG_USB_PLL_480_CTRL_EN_USB_CLKS (1 6)
+
struct mxs_phy {
struct usb_phy phy;
struct clk *clk;
@@ -108,6 +116,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
void __iomem *base;
struct clk *clk;
struct mxs_phy *mxs_phy;
+ struct regmap *anatop;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -146,11 +155,63 @@ static int mxs_phy_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mxs_phy-phy);
+ /*
+* At mx6x, USB PHY PLL and its output gate is controlled by hardware.
+* It just needs to open the gate at init, if the usb device is
+* in suspend, it will close related PLL automatically without
+* the gate is on or off.
+*/
+
+ anatop = syscon_regmap_lookup_by_compatible(fsl,imx6q-anatop);
+
+ if (!IS_ERR(anatop)) {
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ u32 phy_reg_offset;
+ int ret;
+
+ ret = of_property_read_u32(np, anatop-phy-reg-offset,
+ phy_reg_offset);
+ if (ret) {
+ dev_err(dev, no anatop-phy-reg-offset property set\n);
+ return -EINVAL;
+ }
+
+ regmap_write(anatop, phy_reg_offset + CTRL_SET,
+ BM_ANADIG_USB_PLL_480_CTRL_EN_USB_CLKS);
+ } else {
+ pr_warn(failed to find fsl,imx6q-anatop regmap\n);
+ }
+
return 0;
}
static int mxs_phy_remove(struct platform_device *pdev)
{
+ struct regmap *anatop;
+
+ /* close the clock gate for USB PHY */
+ anatop = syscon_regmap_lookup_by_compatible(fsl,imx6q-anatop);
+
+ if (!IS_ERR(anatop)) {
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ u32 phy_reg_offset;
+ int ret;
+
+ ret = of_property_read_u32(np, anatop-phy-reg-offset,
+ phy_reg_offset);
[PATCH v2 3/4] usb: mxs-phy: add set_suspend API
It needs to call set_suspend during USB suspend/resume
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/otg/mxs-phy.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
index 49727dd..cad16e5 100644
--- a/drivers/usb/otg/mxs-phy.c
+++ b/drivers/usb/otg/mxs-phy.c
@@ -84,6 +84,25 @@ static void mxs_phy_shutdown(struct usb_phy *phy)
clk_disable_unprepare(mxs_phy-clk);
}
+static int mxs_phy_suspend(struct usb_phy *x, int suspend)
+{
+ struct mxs_phy *mxs_phy = to_mxs_phy(x);
+
+ if (suspend) {
+ writel_relaxed(0x, x-io_priv + HW_USBPHY_PWD);
+ writel_relaxed(BM_USBPHY_CTRL_CLKGATE,
+ x-io_priv + HW_USBPHY_CTRL_SET);
+ clk_disable_unprepare(mxs_phy-clk);
+ } else {
+ clk_prepare_enable(mxs_phy-clk);
+ writel_relaxed(BM_USBPHY_CTRL_CLKGATE,
+ x-io_priv + HW_USBPHY_CTRL_CLR);
+ writel_relaxed(0, x-io_priv + HW_USBPHY_PWD);
+ }
+
+ return 0;
+}
+
static int mxs_phy_on_connect(struct usb_phy *phy,
enum usb_device_speed speed)
{
@@ -146,6 +165,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
mxs_phy-phy.label = DRIVER_NAME;
mxs_phy-phy.init = mxs_phy_init;
mxs_phy-phy.shutdown = mxs_phy_shutdown;
+ mxs_phy-phy.set_suspend= mxs_phy_suspend;
mxs_phy-phy.notify_connect = mxs_phy_on_connect;
mxs_phy-phy.notify_disconnect = mxs_phy_on_disconnect;
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 4/4] usb: chipidea: imx: Add system suspend/resume API
During the system suspend/resume procedure, the USB also
needs to go suspend/resume procedure, this patch adds
related APIs. It is tested at i.mx6q sabrelite. Meanwhile,
it fixes the bug that the USB will out of work after
system suspend/resume.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/bits.h|1 +
drivers/usb/chipidea/ci13xxx_imx.c | 61
2 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index ba9c6ef..d1467bb 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -47,6 +47,7 @@
#define PORTSC_FPRBIT(6)
#define PORTSC_SUSP BIT(7)
#define PORTSC_HSPBIT(9)
+#define PORTSC_PHCD BIT(23) /* phy suspend mode */
#define PORTSC_PTC(0x0FUL 16)
/* DEVLC */
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c
b/drivers/usb/chipidea/ci13xxx_imx.c
index 342eab0..dd257b1 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -25,6 +25,7 @@
#include linux/mfd/syscon.h
#include ci.h
+#include bits.h
#include ci13xxx_imx.h
#define pdev_to_phy(pdev) \
@@ -321,6 +322,63 @@ static int ci13xxx_imx_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int ci13xxx_imx_suspend(struct device *dev)
+{
+ struct ci13xxx_imx_data *data =
+ platform_get_drvdata(to_platform_device(dev));
+ struct platform_device *plat_ci;
+ struct ci13xxx *ci;
+
+ plat_ci = data-ci_pdev;
+ ci = platform_get_drvdata(plat_ci);
+
+ hw_write(ci, OP_PORTSC, PORTSC_PHCD, 1);
+
+ if (data-phy)
+ usb_phy_set_suspend(data-phy, 1);
+
+ clk_disable_unprepare(data-clk);
+
+ return 0;
+}
+
+static int ci13xxx_imx_resume(struct device *dev)
+{
+ int ret;
+ struct ci13xxx_imx_data *data =
+ platform_get_drvdata(to_platform_device(dev));
+ struct platform_device *plat_ci;
+ struct ci13xxx *ci;
+
+ plat_ci = data-ci_pdev;
+ ci = platform_get_drvdata(plat_ci);
+
+ ret = clk_prepare_enable(data-clk);
+ if (ret) {
+ dev_err(dev,
+ Failed to prepare or enable clock, err=%d\n, ret);
+ return ret;
+ }
+
+ if (hw_read(ci, OP_PORTSC, PORTSC_PHCD)) {
+ hw_write(ci, OP_PORTSC, PORTSC_PHCD, 0);
+ /* Some clks sync between Controller and USB PHY */
+ mdelay(1);
+ }
+
+ if (data-phy)
+ usb_phy_set_suspend(data-phy, 0);
+
+ return ret;
+}
+
+static const struct dev_pm_ops ci13xxx_imx_pm_ops = {
+ .suspend= ci13xxx_imx_suspend,
+ .resume = ci13xxx_imx_resume,
+};
+#endif
+
static const struct of_device_id ci13xxx_imx_dt_ids[] = {
{ .compatible = fsl,imx27-usb, },
{ /* sentinel */ }
@@ -334,6 +392,9 @@ static struct platform_driver ci13xxx_imx_driver = {
.name = imx_usb,
.owner = THIS_MODULE,
.of_match_table = ci13xxx_imx_dt_ids,
+#ifdef CONFIG_PM
+ .pm = ci13xxx_imx_pm_ops,
+#endif
},
};
--
1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/5] mmc: dw_mmc: Add disable-wp device tree property
On Fri, Jan 11, 2013 at 09:03:50AM -0800, Doug Anderson wrote: The disable-wp property is used to specify that a given SD card slot doesn't have a concept of write protect. This eliminates the need for special case code for SD slots that should never be write protected (like a micro SD slot or a dev board). The dw_mmc driver is special in needing to specify disable-wp because the lack of a wp-gpios property means to use the special purpose write protect line. On some other mmc devices the lack of wp-gpios means that write protect should be disabled. Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Seungwon Jeon tgih@samsung.com Acked-by: Olof Johansson o...@lixom.net Nit below. @@ -825,7 +828,13 @@ static int dw_mci_get_ro(struct mmc_host *mmc) struct dw_mci_board *brd = slot-host-pdata; /* Use platform get_ro function, else try on board write protect */ - if (brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) + + /* + * NOTE: DW_MCI_QUIRK_NO_WRITE_PROTECT will be removed in a future + * patch in the series once reference to it is removed. + */ + if ((brd-quirks DW_MCI_QUIRK_NO_WRITE_PROTECT) || + (slot-quirks DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)) Given that it never worked properly, you could have nuked it first and avoid the extra churn. Still, not a strong enough reason to respin the series, IMHO. -Olof ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/4] input: keyboard: tegra: use devm_* for resource allocation
On Mon, Jan 14, 2013 at 10:24:11PM +, Arnd Bergmann wrote: On Monday 14 January 2013, Thierry Reding wrote: It certainly sounds like a less complicated way to do it. But it also involves adding a function with a made up name and drop a function with a perfectly good name instead. I wouldn't even know what name to choose for the new API. How about devm_ioremap_resource()? Sounds equally fitting, and is shorter. Yes, that sounds good. Thanks for the suggestion. Thierry pgp0aXkH4rCEQ.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[patch] hwmon/max6697: fix memset size in max6697_init_chip()
sizeof(p) was intended instead of sizeof(data). data is a pointer and
p is a 7 character struct. It probably doesn't make a difference most
of the time, but it could result in using uninitialized data.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/hwmon/max6697.c b/drivers/hwmon/max6697.c
index a1c8c0a..d229cc7 100644
--- a/drivers/hwmon/max6697.c
+++ b/drivers/hwmon/max6697.c
@@ -474,7 +474,7 @@ static int max6697_init_chip(struct i2c_client *client)
return 0;
if (!pdata || client-dev.of_node) {
- memset(p, 0, sizeof(data));
+ memset(p, 0, sizeof(p));
max6697_get_config_of(client-dev.of_node, p);
pdata = p;
}
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
