[PATCH] of: Fix address decoding on Bimini and js2x machines
Commit:
e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7
of/address: Handle #address-cells 2 specially
broke real time clock access on Bimini, js2x, and similar powerpc
machines using the maple platform. That code was indirectly relying
on the old (broken) behaviour of the translation for the hypertransport
to ISA bridge.
This fixes it by treating hypertransport as a PCI bus
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: sta...@vger.kernel.org [v3.6+]
---
Rob, if you have no objection I will put that in powerpc -next
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..7c8221d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -106,8 +106,12 @@ static unsigned int of_bus_default_get_flags(const __be32 *
static int of_bus_pci_match(struct device_node *np)
{
- /* vci is for the /chaos bridge on 1st-gen PCI powermacs */
- return !strcmp(np-type, pci) || !strcmp(np-type, vci);
+ /*
+* vci is for the /chaos bridge on 1st-gen PCI powermacs
+* ht is hypertransport
+*/
+ return !strcmp(np-type, pci) || !strcmp(np-type, vci) ||
+ !strcmp(np-type, ht);
}
static void of_bus_pci_count_cells(struct device_node *np,
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 5/7] ARM: shmobile: r8a7740: add DT nodes for three DMAC instance
Hi Magnus
On Wed, 3 Jul 2013, Magnus Damm wrote:
Hi Guennadi,
On Wed, Jun 26, 2013 at 11:40 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
This patch adds Device Tree support for the three DMA controller instances
on r8a7740 in a DMA multiplexer node.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
arch/arm/boot/dts/r8a7740.dtsi | 62
arch/arm/mach-shmobile/setup-r8a7740.c | 12 ++
2 files changed, 74 insertions(+), 0 deletions(-)
Thanks for your work on this.
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -996,7 +996,19 @@ void __init r8a7740_add_early_devices(void)
#ifdef CONFIG_USE_OF
+static struct of_dev_auxdata r8a7740_dmac_auxdata[] = {
+ OF_DEV_AUXDATA(renesas,shdma, 0xfe008020, sh-dma-engine.0,
+ dma_platform_data),
+ OF_DEV_AUXDATA(renesas,shdma, 0xfe018020, sh-dma-engine.1,
+ dma_platform_data),
+ OF_DEV_AUXDATA(renesas,shdma, 0xfe028020, sh-dma-engine.2,
+ dma_platform_data),
+ { }
+};
+
static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst = {
+ OF_DEV_AUXDATA(renesas,shdma-mux, 0, shdma-of.0,
+ r8a7740_dmac_auxdata),
{ }
};
Uhm, what is the reason for adding AUXDATA? For all other cases we
have clearly separated the DT reference bits from the C version
without using AUXDATA. With that approach we can use the default NULL
callbacks for -init_machine(). Now with this patch we're going in the
totally different direction...
Why can't you use DT only for these?
Short answer - because that's how the SH DMA driver, currently in the
next tree ready for Linus to be pulled, is implemented. We had enough
time to discuss this back then, I think, it is a pity this question is
raised only now.
A while ago I read, that it is ok to pass SoC-specific device properties
via auxdata, as opposed to board-specific ones, that have to go via DT. On
shmobile this is also easy to implement - all devices, initialised from
setup-soc.c, i.e. having no board-specific configuration, and defined in
soc.dtsi can just take their configuration from the same platform data,
as in .c case. Another motivation for this is, that we want to get rid of
board-name.c files, but we'll always have setup-soc.c files. With that
in mind I implemented DMAC DT bindings and that also allowed us to so
quickly get them accepted into the mainline. If we needed to initialise
DMAC completely from DT, mainlining would certainly take much longer.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 5/7] ARM: shmobile: r8a7740: add DT nodes for three DMAC instance
Hi Guennadi,
On Wed, Jul 3, 2013 at 3:23 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Magnus
On Wed, 3 Jul 2013, Magnus Damm wrote:
Hi Guennadi,
On Wed, Jun 26, 2013 at 11:40 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
This patch adds Device Tree support for the three DMA controller instances
on r8a7740 in a DMA multiplexer node.
Signed-off-by: Guennadi Liakhovetski g.liakhovetski+rene...@gmail.com
---
arch/arm/boot/dts/r8a7740.dtsi | 62
arch/arm/mach-shmobile/setup-r8a7740.c | 12 ++
2 files changed, 74 insertions(+), 0 deletions(-)
Thanks for your work on this.
--- a/arch/arm/mach-shmobile/setup-r8a7740.c
+++ b/arch/arm/mach-shmobile/setup-r8a7740.c
@@ -996,7 +996,19 @@ void __init r8a7740_add_early_devices(void)
#ifdef CONFIG_USE_OF
+static struct of_dev_auxdata r8a7740_dmac_auxdata[] = {
+ OF_DEV_AUXDATA(renesas,shdma, 0xfe008020, sh-dma-engine.0,
+ dma_platform_data),
+ OF_DEV_AUXDATA(renesas,shdma, 0xfe018020, sh-dma-engine.1,
+ dma_platform_data),
+ OF_DEV_AUXDATA(renesas,shdma, 0xfe028020, sh-dma-engine.2,
+ dma_platform_data),
+ { }
+};
+
static const struct of_dev_auxdata r8a7740_auxdata_lookup[] __initconst =
{
+ OF_DEV_AUXDATA(renesas,shdma-mux, 0, shdma-of.0,
+ r8a7740_dmac_auxdata),
{ }
};
Uhm, what is the reason for adding AUXDATA? For all other cases we
have clearly separated the DT reference bits from the C version
without using AUXDATA. With that approach we can use the default NULL
callbacks for -init_machine(). Now with this patch we're going in the
totally different direction...
Why can't you use DT only for these?
Short answer - because that's how the SH DMA driver, currently in the
next tree ready for Linus to be pulled, is implemented. We had enough
time to discuss this back then, I think, it is a pity this question is
raised only now.
Yes, indeed, in the same way it is a pity that this turns out to be
the only user of AUXDATA.
A while ago I read, that it is ok to pass SoC-specific device properties
via auxdata, as opposed to board-specific ones, that have to go via DT. On
shmobile this is also easy to implement - all devices, initialised from
setup-soc.c, i.e. having no board-specific configuration, and defined in
soc.dtsi can just take their configuration from the same platform data,
as in .c case. Another motivation for this is, that we want to get rid of
board-name.c files, but we'll always have setup-soc.c files. With that
in mind I implemented DMAC DT bindings and that also allowed us to so
quickly get them accepted into the mainline. If we needed to initialise
DMAC completely from DT, mainlining would certainly take much longer.
Neither DMAC nor DT have ever been rushing, so I'm not sure why you
are doing that now. Both those are about correctness. We are fine
without DMAC and without DT for a majority of the cases. So let's get
it right instead of half-right.
Sorry to say this, but from my perspective the AUXDATA solution above
seems to be a rushed short term solution to a more long term problem.
Actually, I'm not sure how you ever came to think that was a good
idea.
Please show how you plan on going from AUXDATA to DT only. I am fine
with something similar to the PFC implementation that has SoC-specifc
bits written in C outside arch/arm, but I'd rather not use AUXDATA for
future code.
Thanks,
/ magnus
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Best practice device tree design for display subsystems/DRM
-Original Message- From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On Behalf Of Stephane Marchesin Sent: Wednesday, July 03, 2013 10:46 AM To: Dave Airlie Cc: Jean-Francois Moine; Daniel Drake; devicetree-discuss@lists.ozlabs.org; dri-de...@lists.freedesktop.org; Russell King; Sebastian Hesselbarth Subject: Re: Best practice device tree design for display subsystems/DRM On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie airl...@gmail.com wrote: On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: I am against a super node which contains lcd and dcon/ire nodes. You can enable those devices on a per board basis. We add them to dove.dtsi but disable them by default (status = disabled). The DRM driver itself should get a video-card node outside of soc/internal-regs where you can put e.g. video memory hole (or video mem size if it will be taken from RAM later) About the unusual case, I guess we should try to get both lcd controllers into one DRM driver. Then support mirror or screen extension X already provides. For those applications where you want X on one lcd and some other totally different video stream - wait for someone to come up with a request or proposal. Well, all I can say then is that the onus is on those who want to treat the components as separate devices to come up with some foolproof way to solve this problem which doesn't involve making assumptions about the way that devices are probed and doesn't end up creating artificial restrictions on how the devices can be used - and doesn't end up burdening the common case with lots of useless complexity that they don't need. It's _that_ case which needs to come up with a proposal about how to handle it because you _can't_ handle it at the moment in any sane manner which meets the criteria I've set out above, and at the moment the best proposal by far to resolve that is the super node approach. There is _no_ way in the device model to combine several individual devices together into one logical device safely when the subsystem requires that there be a definite point where everything is known. That applies even more so with -EPROBE_DEFER. With the presence of such a thing, there is now no logical point where any code can say definitively that the system has technically finished booting and all resources are known. That's the problem - if you don't od the super-node approach, you end up with lots of individual devices which you have to figure out some way of combining, and coping with missing ones which might not be available in the order you want them to be, etc. That's the advantage of the super node approach - it's a container to tell you what's required in order to complete the creation of the logical device, and you can parse the sub-nodes to locate the information you need. I think such an approach would lead to drm drivers which all parse their super nodes themselves and driver authors would become very creative how such a node should look like. Also this gets messy with i2c devices which are normally registered under their i2c bus masters. With the super node approach these would have to live under the super node, maybe with a phandle to the i2c bus master. This again probably leads to very SoC specific solutions. It also doesn't solve the problem that the i2c bus master needs to be registered by the time the DRM driver probes. On i.MX the IPU unit not only handles the display path but also the capture path. v4l2 begins to evolve an OF model in which each (sub)device has its natural position in the devicetree; the devices are then connected with phandles. I'm not sure how good this will work together with a super node approach. An alternative as I see it is that DRM - and not only DRM but also the DRM API and Xorg - would need to evolve hotplug support for the various parts of the display subsystem. Do we have enough people with sufficient knowledge and willingness to be able to make all that happen? I don't think we do, and I don't see that there's any funding out there to make such a project happen, which would make it a volunteer/spare time effort. +1 for this solution, even if this means more work to get from the ground. Do we really need full hotplug support in the DRM API and Xorg? I mean it would really be nice if Xorg detected a newly registered device, but as a start it should be sufficient when Xorg detects what's there when it starts, no? Since fbdev and fbcon sit on top of drm to provide the console currently I'd also expect some fun with them. How do I get a console if I have no outputs at
Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: I am against a super node which contains lcd and dcon/ire nodes. You can enable those devices on a per board basis. We add them to dove.dtsi but disable them by default (status = disabled). The DRM driver itself should get a video-card node outside of soc/internal-regs where you can put e.g. video memory hole (or video mem size if it will be taken from RAM later) About the unusual case, I guess we should try to get both lcd controllers into one DRM driver. Then support mirror or screen extension X already provides. For those applications where you want X on one lcd and some other totally different video stream - wait for someone to come up with a request or proposal. Well, all I can say then is that the onus is on those who want to treat the components as separate devices to come up with some foolproof way to solve this problem which doesn't involve making assumptions about the way that devices are probed and doesn't end up creating artificial restrictions on how the devices can be used - and doesn't end up burdening the common case with lots of useless complexity that they don't need. It's _that_ case which needs to come up with a proposal about how to handle it because you _can't_ handle it at the moment in any sane manner which meets the criteria I've set out above, and at the moment the best proposal by far to resolve that is the super node approach. There is _no_ way in the device model to combine several individual devices together into one logical device safely when the subsystem requires that there be a definite point where everything is known. That applies even more so with -EPROBE_DEFER. With the presence of such a thing, there is now no logical point where any code can say definitively that the system has technically finished booting and all resources are known. That's the problem - if you don't od the super-node approach, you end up with lots of individual devices which you have to figure out some way of combining, and coping with missing ones which might not be available in the order you want them to be, etc. That's the advantage of the super node approach - it's a container to tell you what's required in order to complete the creation of the logical device, and you can parse the sub-nodes to locate the information you need. I think such an approach would lead to drm drivers which all parse their super nodes themselves and driver authors would become very creative how such a node should look like. Also this gets messy with i2c devices which are normally registered under their i2c bus masters. With the super node approach these would have to live under the super node, maybe with a phandle to the i2c bus master. This again probably leads to very SoC specific solutions. It also doesn't solve the problem that the i2c bus master needs to be registered by the time the DRM driver probes. On i.MX the IPU unit not only handles the display path but also the capture path. v4l2 begins to evolve an OF model in which each (sub)device has its natural position in the devicetree; the devices are then connected with phandles. I'm not sure how good this will work together with a super node approach. An alternative as I see it is that DRM - and not only DRM but also the DRM API and Xorg - would need to evolve hotplug support for the various parts of the display subsystem. Do we have enough people with sufficient knowledge and willingness to be able to make all that happen? I don't think we do, and I don't see that there's any funding out there to make such a project happen, which would make it a volunteer/spare time effort. +1 for this solution, even if this means more work to get from the ground. Do we really need full hotplug support in the DRM API and Xorg? I mean it would really be nice if Xorg detected a newly registered device, but as a start it should be sufficient when Xorg detects what's there when it starts, no? Since fbdev and fbcon sit on top of drm to provide the console currently I'd also expect some fun with them. How do I get a console if I have no outputs at boot, but I have crtcs? do I just wait around until an output appears. I thought the console/fb stuff should go away. There are a number of issues with hotplugging encoders and connectors at runtime, when really the SoC/board designer knows what it provides and should be able to tell the driver in some fashion. The main problems when I played with hot adding eDP on Intel last time, are we have grouping of crtc/encoder/connectors for multi-seat future use, these groups need to be updated,
Re: Best practice device tree design for display subsystems/DRM
On Tue, Jul 02, 2013 at 11:14:45PM +0100, Russell King wrote: On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: Have you also considered how suspend/resume works in such a place, where every driver is independent? The ChromeOS guys have bitched before about the exynos driver which is has lots of sub-drivers, how do you control the s/r ordering in a crazy system like that? I'd prefer a central driver, otherwise there is too many moving parts. From earlier in the evolution of Armada DRM, that has also been my preferred idea - though probably not quite how people think. My idea was to have a separate driver assemble all the constituent parts, and then register the armada-drm platform device providing via platform resources and/or platform data all the necessary information (maybe not even bothering to decode the OF nodes but just provide a collection of nodes for each consituent part.) This sounds similar to what ASoC does. There a sound device is a devicenode which only has phandles to the various components which are still registered by the regular device model. What I'm currently missing in DRM is a place where I can register the various components (analog to snd_soc_register_codec / snd_soc_register_component) until some upper layer DRM driver collects the pieces and registers a DRM device (as said, no need for real hotplug). If we had this component, there would be no need for i2c encoder helpers which insist on registering their own i2c devices instead of using the devices which are found in the devicetree. Such a thing could be turned into a generic solution for all the multi-part drivers. If we use Sebastian's idea of using phandles (it seems there's a precident for it with the direction v4l2 is going to solve a similar problem) then we likely have a standard way of describing component-ized display setups in DT. What the v4l2 guys are currently doing is definitely worth looking at before we come up with a different approach for DRM. v4l2 has the same problems, it would be a shame if we come up with a totally different solution. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Best practice device tree design for display subsystems/DRM
-Original Message- From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On Behalf Of Russell King Sent: Wednesday, July 03, 2013 4:08 AM To: Daniel Drake Cc: Jean-François Moine; devicetree-discuss@lists.ozlabs.org; dri- de...@lists.freedesktop.org; Sebastian Hesselbarth Subject: Re: Best practice device tree design for display subsystems/DRM On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote: On Tue, Jul 2, 2013 at 12:43 PM, Russell King r...@arm.linux.org.uk wrote: I will point out that relying on driver probing orders has already been stated by driver model people to be unsafe. This is why I will not adopt such a solution for my driver; it is a bad design. Just to clarify, what you're objecting to is effectively the following? Because it is not guaranteed in the future that the probe order will be the same as the platform_driver_register() calls? Correct. Consider what happens if the devices are registered after the driver(s) have been registered, which may not be in the correct order. That's true but how drivers could be registered prior to devices? The devices registering codes are built in kernel image so the drivers cannot be registered prior to devices as long as we don't modify the devices to be registered first. Is there any case that driver should be registered first? Thanks, Inki Dae -- Russell King ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
Gururaja,
On 7/2/2013 11:42 AM, Sekhar Nori wrote:
Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: b-cous...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
-compatible = ti,da830-rtc;
+compatible = ti,am3352-rtc;
compatible is a list so you can instead do:
compatible = ti,am3352-rtc, ti,da830-rtc;
That way the dts works irrespective of driver updates. When driver
supports enhanced features of hardware, they are available to the user
else the basic functionality still works.
On doing some experiments myself, the of_device_id which gets selected
during probe depends on the order in which its entry appears in the
match table inside the driver rather than how the compatible string is
written. I think this puts undue dependency on how the driver is
written, so I am okay with providing a single compatible value like the
way you have done ATM.
I do think the string appearing first in the compatible list is what
should be selected if a match is available but I am not sure if there
are other considerations due to which of_match_device() is written the
way it is written.
Thanks,
Sekhar
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 08:55, Sascha Hauer wrote: On Wed, Jul 03, 2013 at 08:02:05AM +1000, Dave Airlie wrote: Have you also considered how suspend/resume works in such a place, where every driver is independent? The ChromeOS guys have bitched before about the exynos driver which is has lots of sub-drivers, how do you control the s/r ordering in a crazy system like that? I'd prefer a central driver, otherwise there is too many moving parts. Composing a DRM device out of subdevices doesn't necessarily mean the components should be suspended/resumed in arbitrary order. The DRM device should always be suspended first (thus deactivating sub devices as necessary and as done already) and resumed last. Note that a super node approach does not solve this magically. We would still have to make sure that the i2c bus masters on our SoC are suspended after the DRM device. +1 for a video card supernode that at best should be some very generic node with standard properties provided by DRM backend. IIRC there was a proposal for of_video_card a while ago. At least for Marvell SoCs, moving device nodes out of the bus structure will not work. The parent bus is _required_ for address mapping as the base address is configurable. Using phandles can solve this without moving nodes. Also, having separate device nodes does not require a separate driver for each nodes. All nodes get platform_devices registered, but you can choose not to have a matching driver for it. Then the video card super node can pick up that nodes by using the phandles passed and register a single DRM driver claiming the devices. Moreover, if we talk about SoC graphics, we have to take audio into account. If you move all nodes to your video card super node, you will add another bunch of issues for ASoC linking to e.g. the I2C HDMI transmitter SPDIF codec. IMHO phandles and super node subnodes are equivalent from a driver point-of-view but phandles are more likely to cause less pain for other subsystems. The super node approach will also allow to have the same SoC/board components being used as single video card or multiple video cards environment. There is virtually no way to automatically determine what devices belong to your video card(s) in a SoC, so we need something to describe those cards. One thing I am concerned about is what Sascha pointed out above. If you hook up an external I2C encoder to your card, you cannot make sure I2C bus is suspended before DRM device. To be honest, proposing a solution for that is still way beyond my expertise wrt to Linux internals, so I am not even trying it. Maybe I am even missing a very important point for the super node/phandle proposal, if so, please clarify. Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[Patch V2 4/4] ARM: dts: AM33XX: update rtc node compatibility
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[Patch V2 2/4] ARM: Davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
commit 75c99bb0006ee065b4e2995078d779418b0fab54
Author: Sekhar Nori nsek...@ti.com
davinci: da8xx/omap-l1: mark RTC as a wakeup source
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Russell King li...@arm.linux.org.uk
---
Changes in V2:
- Coding style corrections (remove extra space)
- use prefix ARM: for commit subject keeping with arch/arm convention
:100644 100644 bf57252... 9140b1c... M arch/arm/mach-davinci/devices-da8xx.c
arch/arm/mach-davinci/devices-da8xx.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..9140b1c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
int da8xx_register_rtc(void)
{
- int ret;
-
- ret = platform_device_register(da8xx_rtc_device);
- if (!ret)
- /* Atleast on DA850, RTC is a wakeup source */
- device_init_wakeup(da8xx_rtc_device.dev, true);
-
- return ret;
+ return platform_device_register(da8xx_rtc_device);
}
static void __iomem *da8xx_ddr2_ctlr_base;
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[Patch V2 3/4] rtc: omap: add rtc wakeup support to alarm events
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc device dt
compatibility node.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
Changes in V2:
- Coding style corrections (use lower case for hex numbers)
- use [AM/am]3352 instead of [AM/am]335x to keep the all
usages in sync.
- Use index defined for struct members so they remain in sync
:100644 100644 b47aa41... 5a0f02d... M
Documentation/devicetree/bindings/rtc/rtc-omap.txt
:100644 100644 761919d... c2e18fe... M drivers/rtc/rtc-omap.c
Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 +-
drivers/rtc/rtc-omap.c | 60 +---
2 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..5a0f02d 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -1,7 +1,11 @@
TI Real Time Clock
Required properties:
-- compatible: ti,da830-rtc
+- compatible:
+ - ti,da830-rtc - for RTC IP used similar to that on DA8xx SoC family.
+ - ti,am3352-rtc - for RTC IP used similar to that on AM335x SoC
family.
+ This RTC IP has special WAKE-EN Register to enable
+ Wakeup generation for event Alarm.
- reg: Address range of rtc register set
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 761919d..c2e18fe 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,8 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_IRQWAKEEN 0x7c
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -96,12 +98,21 @@
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_IRQWAKEEN bit fields: */
+#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN(11)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+/*
+ * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup
+ * generation for event Alarm.
+ */
+#defineOMAP_RTC_HAS_IRQWAKEEN 0x2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -301,12 +312,18 @@ static struct rtc_class_ops omap_rtc_ops = {
static int omap_rtc_alarm;
static int omap_rtc_timer;
-#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_AM3352_IDX1
+#defineOMAP_RTC_DATA_DA830_IDX 2
static struct platform_device_id omap_rtc_devtype[] = {
{
.name = DRIVER_NAME,
- }, {
+ },
+ [OMAP_RTC_DATA_AM3352_IDX] = {
+ .name = am3352-rtc,
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
+ },
+ [OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
@@ -318,6 +335,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
+ { .compatible = ti,am3352-rtc,
+ .data = omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
@@ -466,16 +486,28 @@ static u8 irqstat;
static int omap_rtc_suspend(struct device *dev)
{
+ u8 irqwake_stat;
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(pdev);
+
irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
/* FIXME the RTC alarm is not currently acting as a wakeup event
-* source, and in fact this enable() call is just saving a flag
-* that's never used...
+* source on some platforms, and in fact this enable() call is just
+* saving a flag that's never used...
*/
- if
[Patch V2 1/4] rtc: omap: restore back (hard-code) wakeup support
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. However, rtc wake support on OMAP1 is broken. Hence the device_init_wakeup() was removed from rtc-omap driver and moved to platform board files that supported it (DA850/OMAP-L138). [1] However, recently [2] it was suggested that driver should always do a device_init_wakeup(dev, true). Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup Also, with the new DT boot-up, board file doesn't exist and hence there is no way to have device wakeup support rtc. The fix for above issues, is to hard code device_init_wakeup() inside driver and let platforms that don't need this, handle it through the sysfs power entry. [1] https://patchwork.kernel.org/patch/136731/ [2] http://www.mail-archive.com/davinci-linux-open-source@linux. davincidsp.com/msg26077.html Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Acked-by: Kevin Hilman khil...@linaro.org Cc: Alessandro Zummo a.zu...@towertech.it Cc: rtc-li...@googlegroups.com --- :100644 100644 b0ba3fc... 761919d... M drivers/rtc/rtc-omap.c drivers/rtc/rtc-omap.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index b0ba3fc..761919d 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -423,6 +423,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev) *is write-only, and always reads as zero...) */ + device_init_wakeup(pdev-dev, true); + if (new_ctrl (u8) OMAP_RTC_CTRL_SPLIT) pr_info(%s: split power mode\n, pdev-name); -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Best practice device tree design for display subsystems/DRM
-Original Message-
From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
[mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
Behalf Of Sebastian Hesselbarth
Sent: Wednesday, July 03, 2013 6:41 AM
To: Daniel Drake
Cc: Jean-Francois Moine; devicetree-discuss@lists.ozlabs.org; dri-
de...@lists.freedesktop.org; Russell King
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/02/2013 11:04 PM, Daniel Drake wrote:
On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
I am against a super node which contains lcd and dcon/ire nodes. You
can
enable those devices on a per board basis. We add them to dove.dtsi but
disable them by default (status = disabled).
The DRM driver itself should get a video-card node outside of
soc/internal-regs where you can put e.g. video memory hole (or video
mem size if it will be taken from RAM later)
For completeness of the discussion, and my understanding too, can you
explain your objections to the display super-node in a bit more
detail?
lcd-controller nodes and dcon node will need to be children of
internal-regs nodes. The internal-regs node is required for address
translation as the mbus base address can be configured. The above does
not permit a super-node - but you cannot have the nodes above outside
of internal-regs.
As Russell stated, he wants a proposal for the unusual case i.e.
you have two lcd controllers. You use one for Xorg and the other for
e.g. running a linux terminal console.
This would require some reference from the super node to the lcd
controller to sort out which DRM device (represented by the super
node) should be using which lcd controller device.
Using status = disabled alone will only allow to enable or disable
lcd controller nodes but not assign any of it to your two super-nodes.
So my current proposal after thinking about Russell's statements
whould be phandles as Jean-Francois already mentioned. I am not sure
what OF maintainers will think about it, but that is another thing.
Basically, you will have:
(Note: names and property-names are just to show how it could work,
and example is joined from possible future dove.dtsi and dove-board.dts)
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /* video-mem hole */
/* later: linux,video-memory-size = 0x100; */
marvell,video-devices = lcd0 lcd1 dcon;
};
/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd0;
};
card1 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd1;
};
};
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should be considered for
all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
and so no. So I *strongly* object to it. All we have to do is to keep the
dtsi file as is, and to find other better way that can be used commonly in
DRM.
Thanks,
Inki Dae
mbus {
compatible = marvell,dove-mbus;
ranges = ...;
sb-regs {
ranges = 0 0xf100 0 0x10;
...
}
nb-regs {
ranges = 0 0xf180 0 0x10;
lcd0: lcd-controller@2 {
compatible = marvell,armada-510-lcd;
reg = 0x2 0x1000;
interrupts = 47;
...
/* use EXTCLK0 with lcd0 */
clocks = ext_clk0;
clock-names = extclk0;
marvell,external-encoder = tda998x;
};
lcd1: lcd-controller@1 {
compatible = marvell,armada-510-lcd;
reg = 0x1 0x1000;
interrupts = 46;
...
/* use LCDPLL with lcd1 */
clocks = lcd_pll_clk;
clock-names = lcdpll;
};
}
};
i2c0 {
tda998x: hdmi-transmitter@60 {
compatible = nxp,tda19988;
reg = 0x60;
...
}
};
Each lcd controller node represents a platform_device and the display
nodes above should look up phandles and determine type (ctrc or dcon)
by compatible string of the nodes the phandles point to.
Sebastian
Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /* video-mem hole */
/* later: linux,video-memory-size = 0x100; */
marvell,video-devices = lcd0 lcd1 dcon;
};
/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd0;
};
card1 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd1;
};
};
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should be considered for
all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
and so no. So I *strongly* object to it. All we have to do is to keep the
dtsi file as is, and to find other better way that can be used commonly in
DRM.
+1 for not encoding the projected usecase of the graphics subsystem into
the devicetree. Whether the two LCD controllers shall be used together
or separately should not affect the devicetree. devicetree is about
hardware description, not configuration.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 11:02, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /* video-mem hole */
/* later: linux,video-memory-size = 0x100; */
marvell,video-devices = lcd0 lcd1 dcon;
};
/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd0;
};
card1 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd1;
};
};
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should be considered for
all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
and so no. So I *strongly* object to it. All we have to do is to keep the
dtsi file as is, and to find other better way that can be used commonly in
DRM.
Sascha, Inki,
can you clarify how the above will _not_ allow you to write a fb driver
exploiting the cardX nodes?
While lcd controller and dcon are physically available, the video card
is just a virtual combination of those.
+1 for not encoding the projected usecase of the graphics subsystem into
the devicetree. Whether the two LCD controllers shall be used together
or separately should not affect the devicetree. devicetree is about
hardware description, not configuration.
Have you had a look at gpio-leds? It _is_ actually a configuration of
GPIO to be used as LED triggers. IMHO DT is just fine for describing
even virtual hardware you make up out of existing devices. Without it
there is no way for the subsystems to determine the configuration.
Regarding gpio-leds, how should the driver know the single gpio line
out of tens of available lines, if you do not use a virtual gpio led
node to describe it?
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Best practice device tree design for display subsystems/DRM
-Original Message-
From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com]
Sent: Wednesday, July 03, 2013 6:09 PM
To: Sascha Hauer
Cc: Inki Dae; 'Daniel Drake'; 'Jean-Francois Moine'; devicetree-
disc...@lists.ozlabs.org; 'Russell King'; dri-de...@lists.freedesktop.org
Subject: Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 11:02, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /* video-mem hole */
/* later: linux,video-memory-size = 0x100; */
marvell,video-devices = lcd0 lcd1 dcon;
};
/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd0;
};
card1 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd1;
};
};
Sorry but I'd like to say that this cannot be used commonly. Shouldn't
you
really consider Linux framebuffer or other subsystems? The above dtsi
file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should be considered
for
all device drivers based on other subsystems: i.e., Linux framebuffer,
DRM,
and so no. So I *strongly* object to it. All we have to do is to keep
the
dtsi file as is, and to find other better way that can be used commonly
in
DRM.
Sascha, Inki,
can you clarify how the above will _not_ allow you to write a fb driver
exploiting the cardX nodes?
That's not whether we can write device driver or not. dtsi is common spot in
other subsystems. Do you think the cardX node is meaningful to other
subsystems?
Thanks,
Inki Dae
While lcd controller and dcon are physically available, the video card
is just a virtual combination of those.
+1 for not encoding the projected usecase of the graphics subsystem into
the devicetree. Whether the two LCD controllers shall be used together
or separately should not affect the devicetree. devicetree is about
hardware description, not configuration.
Have you had a look at gpio-leds? It _is_ actually a configuration of
GPIO to be used as LED triggers. IMHO DT is just fine for describing
even virtual hardware you make up out of existing devices. Without it
there is no way for the subsystems to determine the configuration.
Regarding gpio-leds, how should the driver know the single gpio line
out of tens of available lines, if you do not use a virtual gpio led
node to describe it?
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /* video-mem hole */
/* later: linux,video-memory-size = 0x100; */
marvell,video-devices = lcd0 lcd1 dcon;
};
/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd0;
};
card1 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd1;
};
};
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should be considered for
all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
and so no. So I *strongly* object to it. All we have to do is to keep the
dtsi file as is, and to find other better way that can be used commonly in
DRM.
+1 for not encoding the projected usecase of the graphics subsystem into
the devicetree. Whether the two LCD controllers shall be used together
or separately should not affect the devicetree. devicetree is about
hardware description, not configuration.
And if we listen to that argument, then this problem is basically
impossible to solve sanely.
Are we really saying that we have no acceptable way to represent
componentized devices in DT? If that's true, then DT fails to represent
quite a lot of ARM hardware, and frankly we shouldn't be using it. I
can't believe that's true though.
The problem is that even with an ASoC like approach, that doesn't work
here because there's no way to know how many components to expect.
That's what the supernode is doing - telling us what components group
together to form a device.
Moreover, if you pay attention to my proposal, what you will realise is
that it isn't DRM specific - it's totally subsystem agnostic. All it's
doing is collecting a set of other devices together and only then
publishing a device representing the full set of sub-devices.
Now think about that: what is DRM specific about that solution? What
is the DRM specific about collecting a set of devices together and
publishing a new device ?
How is this not describing the hardware? If I attach a HDMI transceiver
to the DCON which is then connected to LCD0, is it not describing the
hardware to put into DT that LCD0, DCON, and the HDMI transceiver are
all connected together and therefore are required? One of the points of
DT after all is that it can and should be used to represent the
relationship between devices.
No - using the tree approach doesn't work, because LCD0, LCD1 and DCON
are all on the same physical bus, but are themselves connected together.
If you like, there are multiple heirarchies here - there's the bus
heirarchy, and then there's the device heirarchy. Both of these
heirarchies need to be represented in DT, otherwise you're not describing
the hardware properly.
--
Russell King
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote: That's not whether we can write device driver or not. dtsi is common spot in other subsystems. Do you think the cardX node is meaningful to other subsystems? Yes, because fbdev could also use it to solve the same problem which we're having with DRM. -- Russell King ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/documentation: Update s5m8767-regulator bindings document
On Mon, Jun 24, 2013 at 03:06:57PM +0530, Sachin Kamat wrote: s5m8767 regulator is used on Exynos platforms which use pin controller to configure GPIOs. Update the example accordingly. Applied, thanks. Please use subject lines that match the subsystem and try to make your changelogs clearer. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 0/8] Generic PHY Framework
Hi, On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote: Hi Kishon, -Original Message- From: ABRAHAM, KISHON VIJAY Sent: Wednesday, June 26, 2013 5:17 PM To: grant.lik...@linaro.org; t...@atomide.com; Balbi, Felipe; ABRAHAM, KISHON VIJAY; a...@arndb.de; swar...@nvidia.com; sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org; gre...@linuxfoundation.org; akpm@linux- foundation.org Cc: rob.herr...@calxeda.com; r...@landley.net; li...@arm.linux.org.uk; benoit.cous...@linaro.org; mche...@redhat.com; ces...@cesarb.net; da...@davemloft.net; Nayak, Rajendra; shawn@linaro.org; Shilimkar, Santosh; devicetree-discuss@lists.ozlabs.org; linux- d...@vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian, George Subject: [PATCH v9 0/8] Generic PHY Framework Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. I would like to use this framework for a smart-card controller connected to a smart-card phy. I have some questions and would like to get feedback on the same. glad to know that :-) I am using “TDA8026 Smartcard PHY from NXP. Here is the link for datasheet and app note for the same. The smart card controller is inside the TI SoC I am working with. Datasheet : www.nxp.com/documents/data_sheet/TDA8026.pdf? Appnote : http://www.nxp.com/documents/application_note/AN10724.pdf The TI SoC details are not public (yet). I can provide details to you offline. Brief about operation: - The controller can work with and without a PHY - When not using PHY, it is limited to talking to a single smart card. There is also a need to put external de-activation logic on card removal for this case. - With a PHY you can use more than one smart card. - Phy has 5 slots : 1 for smart card (credit/debit/other card with chip) and others for SAM – SIM like modules - Once the PHY is initialized, there are some operations that the controller can request of the PHY like: - Card configurations - set voltage - Activation of card - ATR – Answer to reset - Warm reset - ADPU exchange - Deactivation ( Normal/Emergency) hmm.. We should think about extending the phy_ops to include these operations (something like phy_smart_card_ops so that other smart_card PHYs will also be able to use it). - In the mode when smartcard controller talks directly to the card without the need for a PHY, all the above operations will be carried out by the controller itself My current thought process is to make the controller driver provide the user interface and talk to the PHY using the generic PHY framework you proposed. In the case where there is no PHY, my idea is to create a dummy PHY which uses the controller functionality itself. right. And in the case where you actually have a PHY, create a PHY driver and implement the phy_smart_card_ops and register with the PHY framework. What I seem to be missing from the PHY framework is support for event detection and generic read/write API which will enable the controller to talk to the PHY for the operations listed above and also react to events from the PHY. IMO the event detection should be handled in the PHY driver. And I dint feel the need for a read/write API as phy__ops should be doing that precisely. Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 11:53, Russell King wrote: On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote: That's not whether we can write device driver or not. dtsi is common spot in other subsystems. Do you think the cardX node is meaningful to other subsystems? Yes, because fbdev could also use it to solve the same problem which we're having with DRM. Inki, I do not understand why you keep referring to the SoC dtsi. Im my example, I said that it is made up and joined from both SoC dtsi and board dts. So, of course, lcd controller nodes and dcon are part of dove.dtsi because they are physically available on every Dove SoC. Also, the connection from lcd0 to the external HDMI encoder node is in the board dts because you can happily build a Dove SoC board with a different HDMI encoder or with no encoder at all. The video-card super node is not in any way specific to DRM and describes a virtual graphics card comprising both SoC and board components (on a per-board basis). You can have both DRM or fbdev use that virtual video card node to register your subsystem drivers required to provide video output. I agree to what Sascha said, the decision to put one or two virtual graphics card in the device tree depending on the use case is sketchy. You can have one card/two card on the same board, so at this point device tree is not describing HW but use case. But honestly, I see no way around it and it is the only way to allow to even have the decision for one or two cards at all. There is no way for auto-probing the users intention... Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 11:52, Russell King wrote:
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
video {
/* Single video card w/ multiple lcd controllers */
card0 {
compatible = marvell,armada-510-display;
reg = 0 0x3f00 0x100; /* video-mem hole */
/* later: linux,video-memory-size = 0x100; */
marvell,video-devices = lcd0 lcd1 dcon;
};
/* OR: Multiple video card w/ single lcd controllers */
card0 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd0;
};
card1 {
compatible = marvell,armada-510-display;
...
marvell,video-devices = lcd1;
};
};
Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
really consider Linux framebuffer or other subsystems? The above dtsi file
is specific to DRM subsystem. And I think the dtsi file has no any
dependency on certain subsystem so board dtsi file should be considered for
all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
and so no. So I *strongly* object to it. All we have to do is to keep the
dtsi file as is, and to find other better way that can be used commonly in
DRM.
+1 for not encoding the projected usecase of the graphics subsystem into
the devicetree. Whether the two LCD controllers shall be used together
or separately should not affect the devicetree. devicetree is about
hardware description, not configuration.
And if we listen to that argument, then this problem is basically
impossible to solve sanely.
Are we really saying that we have no acceptable way to represent
componentized devices in DT? If that's true, then DT fails to represent
quite a lot of ARM hardware, and frankly we shouldn't be using it. I
can't believe that's true though.
I think DT is able to describe componentized devices, as long as you
ignore DRM/fbdev/ASoC's demands and try to have a look at the HW without
any specific backend in mind.
We both had a similar discussion about ASoC's separation of bus-side and
codec-side subdevices. In HW, there is no such separation but one single
audio controller (at least on Dove). Moreover, a full featured, again
virtual, sound card comprises a lot more than just what is in the SoC.
There is external codecs, jacks, aso.
The problem is that even with an ASoC like approach, that doesn't work
here because there's no way to know how many components to expect.
That's what the supernode is doing - telling us what components group
together to form a device.
True. The supernode forms a virtual device on top of the individual
components of both SoC and board. For the driver subsystem, all that is
required should be probed by starting from the supernode. If what is
found is not sufficient for the driver subsystem to register a working
subsystem device, bail out. If there is more than you expect, ignore
it and cross your fingers. IMHO DT is not the solution for describing
the world, but it is sufficient for any subsystem driver to find what
it needs to know.
Moreover, if you pay attention to my proposal, what you will realise is
that it isn't DRM specific - it's totally subsystem agnostic. All it's
doing is collecting a set of other devices together and only then
publishing a device representing the full set of sub-devices.
Now think about that: what is DRM specific about that solution? What
is the DRM specific about collecting a set of devices together and
publishing a new device ?
How is this not describing the hardware? If I attach a HDMI transceiver
to the DCON which is then connected to LCD0, is it not describing the
hardware to put into DT that LCD0, DCON, and the HDMI transceiver are
all connected together and therefore are required? One of the points of
DT after all is that it can and should be used to represent the
relationship between devices.
No - using the tree approach doesn't work, because LCD0, LCD1 and DCON
are all on the same physical bus, but are themselves connected together.
If you like, there are multiple heirarchies here - there's the bus
heirarchy, and then there's the device heirarchy. Both of these
heirarchies need to be represented in DT, otherwise you're not describing
the hardware properly.
IMHO DT is more than describing physical connections between devices but
also describing logical connections between devices. While, for example,
a SATA bus master could happily do DMA writes to the GPIO registers just
because it is physically connected to it, it makes no sense. OTOH an LED
connected to a gpio pin is not directly connected to the GPIO register
but at least needs to know who to ask for toggling the line.
I know there may be better examples than those above, but describing
a virtual video card with a supernode connecting separate devices is
Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer wrote: +1 for not encoding the projected usecase of the graphics subsystem into the devicetree. Whether the two LCD controllers shall be used together or separately should not affect the devicetree. devicetree is about hardware description, not configuration. And if we listen to that argument, then this problem is basically impossible to solve sanely. Are we really saying that we have no acceptable way to represent componentized devices in DT? If that's true, then DT fails to represent quite a lot of ARM hardware, and frankly we shouldn't be using it. I can't believe that's true though. The problem is that even with an ASoC like approach, that doesn't work here because there's no way to know how many components to expect. That's what the supernode is doing - telling us what components group together to form a device. Moreover, if you pay attention to my proposal, what you will realise is that it isn't DRM specific - it's totally subsystem agnostic. All it's doing is collecting a set of other devices together and only then publishing a device representing the full set of sub-devices. Now think about that: what is DRM specific about that solution? What is the DRM specific about collecting a set of devices together and publishing a new device ? How is this not describing the hardware? If I attach a HDMI transceiver to the DCON which is then connected to LCD0, is it not describing the hardware to put into DT that LCD0, DCON, and the HDMI transceiver are all connected together and therefore are required? One of the points of DT after all is that it can and should be used to represent the relationship between devices. No - using the tree approach doesn't work, because LCD0, LCD1 and DCON are all on the same physical bus, but are themselves connected together. If you like, there are multiple heirarchies here - there's the bus heirarchy, and then there's the device heirarchy. Both of these heirarchies need to be represented in DT, otherwise you're not describing the hardware properly. And I think with these multiple hierarchies there is some confusion in this thread. The devicetree is structured by the bus hierarchy and we shouldn't change that. The bus hierarchy doesn't necessarily match the device hierarchy though. The supernode has to describe the device hierarchy instead. If it does so by referencing the physical devices by using phandles I'm perfectly fine with this approach. If this even leads to subsystem agnostic code which can be used to compose v4l2, ASoC or DRM devices I'd really love it. The only thing we shouldn't do is to describe a whole virtual device directly under a single node in the devicetree as this breaks when bus hierarchy and device hierarchy differ. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote: But honestly, I see no way around it and it is the only way to allow to even have the decision for one or two cards at all. There is no way for auto-probing the users intention... It's not _just_ about the users intention - for get that, because really it's to do with solving a much bigger question, and that question is: How do we know when all the components are present? In other words, how do we know that we have LCD0 and LCD1 connected to the DCON, which is connected to a LCD and/or a HDMI tranceiver. How do we know that the on-board VGA DACs are wired up and to be used? How do we know which I2C bus the VGA port is connected to, and whether to expect an I2C bus? Let's look at the Cubox setup (sorry, but you _will_ have to use a fixed-width font for this): CPU bus | +-I2C -TDA998X --(HDMI)-- Display || | (RGB888+clock+sync) +-LCD0 -. / +--DCON ---(VGA)--- not wired +-LCD1 (unused)-' DCON can allegedly route the data from LCD0 or LCD1 to the parallel interface which the TDA998x sits on, and/or the VGA interface. In the case of other setups, the TDA998x may be a LCD panel. The OLPC setup (which seems to be the more common case in terms of the on-SoC device structure): CPU bus | +-LCD ---(RGB666+clock+sync) LCD panel and I believe an HDMI tranceiver somewhere. In the above diagrams, LCD and LCD0/LCD1 are essentially all the same basic IP block, so they should use the same driver code. Moreover, each named element is a separate platform device. In the first, to drive that correctly, you need the following before loading the display system: 1. LCD0, and optionally LCD1 and DCON to be found and known to display driver. 2. I2C driver to be probed and available for use. 3. TDA998x to be found and known to display driver. Only once you have all those components can you allow display to load. Now consider the case where the TDA998x is not present but the parallel interface is connected directly to a LCD panel. This then becomes: 1. LCD0, and optionally LCD1 and DCON to be found and known to display driver. 2. LCD panel details known to display driver. If the VGA port is being used, then both of these cases need to be supplemented with: N. I2C bus for VGA DDC to be probed and available for use. N+1. DCON must be known to the display driver. N+2. LCD1 required if different display modes on the devices are required. In the OLPC case, it's just: 1. LCD to be found and known to display driver. 2. LCD panel details known to display driver. What you should be getting from the above is that the platform devices which are required for any kind of display subsystem driver to initialize is not really a function of the software use case, but how (a) the board hardware has been designed and put together, and (b) the internal structure of the SoC. Moreover, the problem which we're facing is this: how does a display driver know which platform devices to expect from a DT description to make the decision that all parts required for the physical wiring of the board are now present. Consider this too: what if you have a LCD panel on your RGB888 interface which is also connected to a HDMI transceiver which can do scaling and re-syncing (basically format conversion - the TDA998x appears to have this capability), and you drive it with a mode suitable for HDMI but not the LCD panel because the driver doesn't know that there's a LCD panel also connected? This is why I feel that the hotplug idea is actually rather unsafe, and if we go down that path we're building in that risk. (And I think the OLPC guys may be have exactly that kind of setup...) -- Russell King ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
* Luciano Coelho coe...@ti.com [130702 13:33]: On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote: On 17:55-20130702, Luciano Coelho wrote: Instead of defining an enumeration with the FW specific values for the different clock rates, use the actual frequency instead. Also add a boolean to specify whether the clock is XTAL or not. Change all board files to reflect this. Cc: Tony Lindgren t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- arch/arm/mach-davinci/board-da850-evm.c |3 +- arch/arm/mach-omap2/board-4430sdp.c |5 ++- ^^ arch/arm/mach-omap2/board-omap3evm.c |3 +- arch/arm/mach-omap2/board-omap4panda.c |3 +- ^^ Please do not add more platform data to platforms that are DT only. Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had been removed in linux-next. I base my tree on wireless-next and it doesn't contain these changes yet. I would only have noticed this when I rebased my tree once the merge window is closed. ;) Thanks for pointing out, I'll make sure these changes will not be there when I send the pull request. Please separate out the minimal pdata and arch/arm/mach-omap2 changes int a immutable branch on v3.11-rc1 that I can also pull in. For v3.12, we're going to be making more boards device tree only, so these changes may otherwise cause pointless merge conflicts. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Best practice device tree design for display subsystems/DRM
-Original Message- From: Sebastian Hesselbarth [mailto:sebastian.hesselba...@gmail.com] Sent: Wednesday, July 03, 2013 7:53 PM To: Russell King Cc: Inki Dae; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-Francois Moine'; devicetree-discuss@lists.ozlabs.org; dri-de...@lists.freedesktop.org Subject: Re: Best practice device tree design for display subsystems/DRM On 07/03/13 11:53, Russell King wrote: On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote: That's not whether we can write device driver or not. dtsi is common spot in other subsystems. Do you think the cardX node is meaningful to other subsystems? Yes, because fbdev could also use it to solve the same problem which we're having with DRM. Inki, I do not understand why you keep referring to the SoC dtsi. Im my example, I said that it is made up and joined from both SoC dtsi and board dts. So, of course, lcd controller nodes and dcon are part of dove.dtsi because they are physically available on every Dove SoC. Also, the connection from lcd0 to the external HDMI encoder node is in the board dts because you can happily build a Dove SoC board with a different HDMI encoder or with no encoder at all. The video-card super node is not in any way specific to DRM and In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0 and lcd1 drivers which are placed in drivers/video/backlight/. And let's assume the following: On board A Display controller - lcd 0 On board B Display controller - lcd 1 On board C Display controller - lcd 0 and lcd 1 Without the super node, user could configure Linux kernel through menuconfig like below; board A: enabling lcd 0, and disabling lcd 1, board B: disabling lcd 0, and enabling lcd 1, board C: enabling lcd 0 and lcd 1. All we have to do is to configure menuconfig to enable only drivers for certain board. Why does fbdev need the super node? Please give me comments if there is my missing point. Thanks, Inki Dae describes a virtual graphics card comprising both SoC and board components (on a per-board basis). You can have both DRM or fbdev use that virtual video card node to register your subsystem drivers required to provide video output. I agree to what Sascha said, the decision to put one or two virtual graphics card in the device tree depending on the use case is sketchy. You can have one card/two card on the same board, so at this point device tree is not describing HW but use case. But honestly, I see no way around it and it is the only way to allow to even have the decision for one or two cards at all. There is no way for auto-probing the users intention... Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10] i2c-designware: make SDA hold time configurable
On Wednesday 26 June 2013, Wolfram Sang wrote:
On Wed, Jun 26, 2013 at 10:55:06AM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com
Applied to for-next, thanks for keeping at it and providing lots of
useful information. Much appreciated!
Sorry, but I got a regression that I didn't find reported elsewhere
so far, even though it breaks a lot of the ARM defconfig builds:
drivers/built-in.o: In function `dw_i2c_probe':
/git/arm-soc/drivers/i2c/busses/i2c-designware-platdrv.c:125: undefined
reference to `__udivdi3'
I suspect you want something like the change below.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index def79b5..57e3a07 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -119,10 +119,13 @@ static int dw_i2c_probe(struct platform_device *pdev)
if (pdev-dev.of_node) {
u32 ht = 0;
u32 ic_clk = dev-get_clk_rate_khz(dev);
+ u64 hold_time;
of_property_read_u32(pdev-dev.of_node,
i2c-sda-hold-time-ns, ht);
- dev-sda_hold_time = ((u64)ic_clk * ht + 50) / 100;
+ hold_time = (u64)ic_clk * ht + 50;
+ do_div(hold_time, 100);
+ dev-sda_hold_time = hold_time;
}
dev-functionality =
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 13:43, Inki Dae wrote:
I do not understand why you keep referring to the SoC dtsi. Im my
example, I said that it is made up and joined from both SoC dtsi and
board dts.
So, of course, lcd controller nodes and dcon are part of dove.dtsi
because they are physically available on every Dove SoC.
Also, the connection from lcd0 to the external HDMI encoder node
is in the board dts because you can happily build a Dove SoC board
with a different HDMI encoder or with no encoder at all.
The video-card super node is not in any way specific to DRM and
In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0
and lcd1 drivers which are placed in drivers/video/backlight/.
And let's assume the following:
On board A
Display controller - lcd 0
On board B
Display controller - lcd 1
On board C
Display controller - lcd 0 and lcd 1
Without the super node, user could configure Linux kernel through menuconfig
like below;
board A: enabling lcd 0, and disabling lcd 1,
board B: disabling lcd 0, and enabling lcd 1,
board C: enabling lcd 0 and lcd 1.
All we have to do is to configure menuconfig to enable only drivers for
certain board. Why does fbdev need the super node? Please give me comments
if there is my missing point.
I assume when you say configure menuconfig you mean
create a CONFIG_DISPLAY_CONTROLLER_AS_USED_ON_BOARD_A,
CONFIG_DISPLAY_CONTROLLER_AS_USED_ON_BOARD_B, ... ?
This finally will require you to have
(a) #ifdef mess for every single board _and_ driver above
(b) new CONFIG_.._BOARD_D plus new #ifdefs in fbdev driver for every
new board
(c) A new set of the above CONFIG_/#ifdef for DRM driver
This can also be done with device_tree and supernode approach,
so for your example above:
BoardA.dts:
video { card0 { video-devices = lcd0; }; };
BoardB.dts:
video { card0 { video-devices = lcd1; }; };
BoardC.dts:
video { card0 { video-devices = lcd0 lcd1; }; };
and in the driver your are prepared for looping over the video-devices
property and parsing the compatible string of the nodes passed.
Sebastian
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 00/12] MBus DT binding: A new hope
On Tuesday 02 July 2013, Jason Gunthorpe wrote: On Sat, Jun 29, 2013 at 04:04:03PM -0300, Ezequiel Garcia wrote: Personally, I can't see any disadvantage, and the binding looks much cleaner now. But of course I can be wrong, and I'm open to discussion. There's another pending issue. Arnd Bergmann has required to add a property to specify the available space within the CPU address space for decoding windows. This property would allow to support fully dynamic mbus window allocation. I wonder if this range is implied - eg it is address space not covered by the memory node or any mbus ranges? Is there a situation where that is not sufficient? I think it's sufficient, yes. It feels odd to have the mbus code rely on the contents of the memory node for that, but it would work. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 08:43:20PM +0900, Inki Dae wrote: In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0 and lcd1 drivers which are placed in drivers/video/backlight/. No, that's totally wrong. Framebuffer drivers are not backlights. Framebuffer drivers go in drivers/video not drivers/video/backlight. And let's assume the following: On board A Display controller - lcd 0 On board B Display controller - lcd 1 On board C Display controller - lcd 0 and lcd 1 Without the super node, user could configure Linux kernel through menuconfig like below; board A: enabling lcd 0, and disabling lcd 1, board B: disabling lcd 0, and enabling lcd 1, board C: enabling lcd 0 and lcd 1. I don't think so. By using menuconfig, you completely miss the point of using DT - which is to allow us to have a single kernel image which can support multiple boards with different configurations, even different SoCs. All we have to do is to configure menuconfig to enable only drivers for certain board. Why does fbdev need the super node? Please give me comments if there is my missing point. fbdev needs the supernode _OR_ some way to specify that information which you're putting into menuconfig, because what's correct for the way one board is physically wired is not correct for how another board is physically wired. With that information in menuconfig, you get a kernel image which can support board A, or board B, or board C but not a single kernel image which can support board A and board B and board C by loading that very same kernel image onto all three boards with just a different DT image. This is the *whole* point of ARM moving over to DT. If we wanted to use menuconfig to sort these kinds of board specific details, we wouldn't be investing so much time and effort into moving over to DT for ARM. In fact, we used to use menuconfig to sort out some of these kinds of details, and we've firmly decided that this is the wrong approach. Today, there is a very strong push towards having a single kernel image which runs on every (modern) ARM board with DT describing not only the board level hardware but also the internal SoC as well. -- Russell King ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 4/9] wl12xx: use frequency instead of enumerations for pdata clocks
On Wed, 2013-07-03 at 04:33 -0700, Tony Lindgren wrote: * Luciano Coelho coe...@ti.com [130702 13:33]: On Tue, 2013-07-02 at 10:02 -0500, Nishanth Menon wrote: On 17:55-20130702, Luciano Coelho wrote: Instead of defining an enumeration with the FW specific values for the different clock rates, use the actual frequency instead. Also add a boolean to specify whether the clock is XTAL or not. Change all board files to reflect this. Cc: Tony Lindgren t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- arch/arm/mach-davinci/board-da850-evm.c |3 +- arch/arm/mach-omap2/board-4430sdp.c |5 ++- ^^ arch/arm/mach-omap2/board-omap3evm.c |3 +- arch/arm/mach-omap2/board-omap4panda.c |3 +- ^^ Please do not add more platform data to platforms that are DT only. Ah, I hadn't realized that board_omap4panda.c and board-4430sdp.c had been removed in linux-next. I base my tree on wireless-next and it doesn't contain these changes yet. I would only have noticed this when I rebased my tree once the merge window is closed. ;) Thanks for pointing out, I'll make sure these changes will not be there when I send the pull request. Please separate out the minimal pdata and arch/arm/mach-omap2 changes int a immutable branch on v3.11-rc1 that I can also pull in. For v3.12, we're going to be making more boards device tree only, so these changes may otherwise cause pointless merge conflicts. Okay. I don't want to freeze my work, I'll continue using my wireless-based tree (which is based on 3.10) for now. When the merge window closes, I'll reorganize all this before sending pull requests, so we can avoid conflicts. Please ignore my changes to board files that will disappear on 3.11 and keep reviewing the rest. ;) -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
2013/7/2 Bo Shen voice.s...@atmel.com: Hi Richard, On 7/2/2013 16:13, Richard Genoud wrote: Please hold on of this, as to the ASoC dmaengine will deal with this. So, we not need do it manually. Now, I am working on it. And will send out the patch soon after testing OK. Ok, I stay tuned ! I think you can go on working with the two patches I send just now. [1]: ASoC: atmel_ssc_dai: move set dma data to startup callback https://patchwork.kernel.org/patch/2811241/ [2]: ASoC: atmel-pcm: use generic dmaengine framework https://patchwork.kernel.org/patch/2811261/ I use your patches 4 ~ 8 do a quick testing, it works. Please note the name of asound.state under /etc in your rootfs should the same with atmel,model in patch 6. Thanks for testing ! I was just doing the same test, it works with aplay -Dplug:default good_music.wav but there's a violent hang (kernel stops, no trace) when I try the record : arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav last thing I see is : dma dma0chan3: atc_control (3) I'll try to trace that. Best regards, Richard. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Tuesday 02 July 2013, Pekon Gupta wrote: (+ CC: devicetree-discuss@lists.ozlabs.org) Changes v3 - v4 - [Patch 1/3] removed MTD_NAND_OMAP_BCH8 MTD_NAND_OMAP_BCH4 from nand/Kconfig ECC scheme selectable via nand DT (nand-ecc-opt). - [*] rebased for l2-mtd.git Do you also fix these build error? /git/arm-soc/drivers/mtd/nand/omap2.c: In function 'omap_nand_probe': /git/arm-soc/drivers/mtd/nand/omap2.c:1964:7: error: 'OMAP_ECC_BCH8_CODE_HW_DETECTION_SW' undeclared (first use in this function) case OMAP_ECC_BCH8_CODE_HW_DETECTION_SW: ^ /git/arm-soc/drivers/mtd/nand/omap2.c:1964:7: note: each undeclared identifier is reported only once for each function it appears in /git/arm-soc/drivers/mtd/nand/omap2.c:1991:7: error: 'OMAP_ECC_BCH4_CODE_HW_DETECTION_SW' undeclared (first use in this function) case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW: ^ Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 0/8] Generic PHY Framework
Hi, On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote: Hi Kishon, -Original Message- From: ABRAHAM, KISHON VIJAY Sent: Wednesday, June 26, 2013 5:17 PM To: grant.lik...@linaro.org; t...@atomide.com; Balbi, Felipe; ABRAHAM, KISHON VIJAY; a...@arndb.de; swar...@nvidia.com; sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org; gre...@linuxfoundation.org; akpm@linux- foundation.org Cc: rob.herr...@calxeda.com; r...@landley.net; li...@arm.linux.org.uk; benoit.cous...@linaro.org; mche...@redhat.com; ces...@cesarb.net; da...@davemloft.net; Nayak, Rajendra; shawn@linaro.org; Shilimkar, Santosh; devicetree-discuss@lists.ozlabs.org; linux- d...@vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian, George Subject: [PATCH v9 0/8] Generic PHY Framework Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. I would like to use this framework for a smart-card controller connected to a smart-card phy. I have some questions and would like to get feedback on the same. glad to know that :-) I am using “TDA8026 Smartcard PHY from NXP. Here is the link for datasheet and app note for the same. The smart card controller is inside the TI SoC I am working with. Datasheet : www.nxp.com/documents/data_sheet/TDA8026.pdf? Appnote : http://www.nxp.com/documents/application_note/AN10724.pdf The TI SoC details are not public (yet). I can provide details to you offline. Brief about operation: -The controller can work with and without a PHY -When not using PHY, it is limited to talking to a single smart card. There is also a need to put external de-activation logic on card removal for this case. -With a PHY you can use more than one smart card. -Phy has 5 slots : 1 for smart card (credit/debit/other card with chip) and others for SAM – SIM like modules -Once the PHY is initialized, there are some operations that the controller can request of the PHY like: - Card configurations - set voltage - Activation of card - ATR – Answer to reset - Warm reset - ADPU exchange - Deactivation ( Normal/Emergency) hmm.. We should think about extending the phy_ops to include these operations (something like phy_smart_card_ops so that other smart_card PHYs will also be able to use it). let's try to avoid use-case specific additions. set_voltage sounds like a regulator thing, but the regulator is controlled through the PHY. I guess it makes sense to have a generic phy_set_voltage() call since even USB can make use of that. For card activation, it sounds like phy_init()/phy_shutdown() would cover it. For warm reset perhaps a phy_reset() callback ? Although that could, easily, get abused. For deactivation, that's phy_shutdown(). ATR and ADPU needs more thought, I guess. -In the mode when smartcard controller talks directly to the card without the need for a PHY, all the above operations will be carried out by the controller itself My current thought process is to make the controller driver provide the user interface and talk to the PHY using the generic PHY framework you proposed. In the case where there is no PHY, my idea is to create a dummy PHY which uses the controller functionality itself. right. And in the case where you actually have a PHY, create a PHY driver and implement the phy_smart_card_ops and register with the PHY framework. I would try to avoid that. Otherwise we will have phy_usb_ops, phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would easily blow up. -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote: [Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly returning from probe with pr_err(), if the required libraries (/lib/bch.c) are not build-in the system. --- [Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC.. @@static int omap_nand_probe(struct platform_device *pdev) + default: + pr_err(selected ECC scheme not supported or not enabled\n); + err = -EINVAL; + goto out_release_mem_region; + } --- However, if you are still seeing this, could you please send me your config? I compile tested your patches too, and did not see any issues with my omap2_defconfig. -- Best Regards, Artem Bityutskiy ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On Wednesday 03 July 2013, Artem Bityutskiy wrote: On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote: [Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly returning from probe with pr_err(), if the required libraries (/lib/bch.c) are not build-in the system. --- [Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC.. @@static int omap_nand_probe(struct platform_device *pdev) + default: + pr_err(selected ECC scheme not supported or not enabled\n); + err = -EINVAL; + goto out_release_mem_region; + } --- However, if you are still seeing this, could you please send me your config? I compile tested your patches too, and did not see any issues with my omap2_defconfig. To clarify: I'm getting this error with randconfig on today's linux-next. I think it only happens with MTD_NAND_ECC_BCH enabled, which is not the default in omap2_defconfig. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/9] wilink: add device tree support
On Wed, 2013-07-03 at 13:13 +0300, Grazvydas Ignotas wrote: Hi, Hi Gražvydas, On Tue, Jul 2, 2013 at 5:55 PM, Luciano Coelho coe...@ti.com wrote: Hi, This is a follow-up on a previous patch set that had a smaller audience. This time, I added the lists and people who were involved in the review of the bindings documentation, since most of my changes in v2 are coming from discussions there. This patch series adds device tree support to the wlcore_sdio driver, which is used by WiLink6, WiLink7 and WiLink8. Could you perhaps consider doing device tree conversion for wl1251 too? With the knowledge you have from working on this series, it would be much easier for you to do it than for someone else, and I don't have much hope someone will do it at all. It's WiLink series chip after all. Without this pandora and N900 are going to lose wifi support after the switch to dt-only kernel. Unfortunately I don't have much time to work on wl1251. I think it wouldn't be too difficult to do though, so patches are welcome. ;) Maybe you could try to make this change and I could support you if needed? I can offer you my help testing things on pandora and I'm sure someone here could try it on N900. I could try it on the N900, if it is still bootable easily with the mainline. ;) -- Cheers, Luca. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/8] wilink: add device tree support
Hi, This patch series adds device tree support to the wlcore_sdio driver, which is used by WiLink6, WiLink7 and WiLink8. The first patches do some clean-up to make the data needed in the wilink device tree node smaller. The remaining patches implement the actual device tree node parsing in wlcore_sdio. I still need to figure out how to add the information about whether the clocks are XTAL or not. I'll send it in a separate patche set. The DTS file changes will be sent separately, since they need to go via different trees. The bindings documentation patch will also be updated and sent separately, once the XTAL issue is solved. Changes in v3: * Remove irq_flags from pdata and handle them in the board files. This caused the wlcore: use irq_flags in pdata instead of hiding it behind a quirk (now 2/8) to be changed considerably, so I removed the Acked-by from Tony. I also added calls to gpio_request_one() for the WiLink IRQ GPIO that were missing in the board files (thanks Felipe); * Added const to the frequency tables in patch 4/8 (thanks Felipe); * Squashed patch 5/9 into the new 2/8; * Added comment about the sdio_set_drvdata() call move in 7/8 (thanks Felipe); * I'm still modifying the panda and 4430sdp board files that are going to be removed in 3.11. Please ignore the changes I made there, I just wanted to make sure they still work with my current tree. Once the 3.11 merge window close, I'll do the relevant merges before I send pull requests (thanks Tony and Nishant). Please review. -- Cheers, Luca. Luciano Coelho (8): wl1251: split wl251 platform data to a separate structure wlcore: set irq_flags in the board files instead of hiding behind a quirk wlcore: remove pwr_in_suspend from platform data wl12xx: use frequency instead of enumerations for pdata clocks wlcore: add initial device tree support to the sdio module wlcore: sdio: add wilink clock providers wlcore: sdio: get clocks from device tree wlcore/wl12xx: check if we got correct clock data from DT arch/arm/mach-davinci/board-da850-evm.c| 11 ++- arch/arm/mach-omap2/board-4430sdp.c| 23 - arch/arm/mach-omap2/board-omap3evm.c | 22 - arch/arm/mach-omap2/board-omap3pandora.c |4 +- arch/arm/mach-omap2/board-omap4panda.c | 39 +++-- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 33 ++- drivers/net/wireless/ti/wilink_platform_data.c | 37 ++-- drivers/net/wireless/ti/wl1251/sdio.c | 12 +-- drivers/net/wireless/ti/wl1251/spi.c |2 +- drivers/net/wireless/ti/wl12xx/main.c | 77 ++-- drivers/net/wireless/ti/wl12xx/wl12xx.h| 28 ++ drivers/net/wireless/ti/wlcore/debugfs.c |2 +- drivers/net/wireless/ti/wlcore/main.c | 26 +++--- drivers/net/wireless/ti/wlcore/sdio.c | 112 ++-- drivers/net/wireless/ti/wlcore/wlcore.h|5 +- drivers/net/wireless/ti/wlcore/wlcore_i.h |1 + include/linux/wl12xx.h | 52 +-- 18 files changed, 398 insertions(+), 90 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization. This will be more
meaningful than driver-specific quirks when we switch to DT.
Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c |8 +-
arch/arm/mach-omap2/board-4430sdp.c | 18 +
arch/arm/mach-omap2/board-omap3evm.c | 19 ++
arch/arm/mach-omap2/board-omap4panda.c | 36 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 30 ++---
drivers/net/wireless/ti/wlcore/debugfs.c |2 +-
drivers/net/wireless/ti/wlcore/main.c| 24 ++---
drivers/net/wireless/ti/wlcore/wlcore.h |5 ++--
include/linux/wl12xx.h |4 ---
9 files changed, 118 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 8a24b6c..544b6fa 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1378,7 +1378,6 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
@@ -1409,6 +1408,13 @@ static __init int da850_wl12xx_init(void)
goto free_wlan_en;
}
+ ret = irq_set_irq_type(gpio_to_irq(DA850_WLAN_IRQ),
+ IRQ_TYPE_EDGE_RISING);
+ if (ret) {
+ pr_err(Could not set wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
ret = wl12xx_set_platform_data(da850_wl12xx_wlan_data);
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..953f620 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
omap4_sdp4430_wifi_mux_init();
omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, GPIO_WIFI_IRQ);
+ if (ret) {
+ pr_err(error requesting wl12xx gpio: %d\n, ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err(error setting wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
if (ret)
pr_err(Error setting wl12xx data: %d\n, ret);
+
ret = platform_device_register(omap_vwlan_device);
if (ret)
pr_err(Error registering wl12xx device: %d\n, ret);
+out:
+ return;
+free:
+ gpio_free(GPIO_WIFI_IRQ);
}
static void __init omap_4430sdp_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..8abce3cd 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -612,12 +612,31 @@ static void __init omap3_evm_wl12xx_init(void)
/* WL12xx WLAN Init */
omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
+
+ ret = gpio_request_one(OMAP3EVM_WLAN_IRQ_GPIO, GPIOF_IN,
+ OMAP3EVM_WLAN_IRQ_GPIO);
+ if (ret) {
+ pr_err(error requesting wl12xx gpio: %d\n, ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO),
+ IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err(error setting wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(omap3evm_wlan_data);
if (ret)
pr_err(error setting wl12xx data: %d\n, ret);
ret = platform_device_register(omap3evm_wlan_regulator);
if (ret)
pr_err(error registering wl12xx device: %d\n, ret);
+out:
+ return;
+free:
+ gpio_free(OMAP3EVM_WLAN_IRQ_GPIO);
#endif
}
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 1e2c75e..5b33626 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -413,20 +413,44
[PATCH v3 1/8] wl1251: split wl251 platform data to a separate structure
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Luciano Coelho coe...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap3pandora.c |4 +--
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
drivers/net/wireless/ti/wilink_platform_data.c | 37
drivers/net/wireless/ti/wl1251/sdio.c | 12
drivers/net/wireless/ti/wl1251/spi.c |2 +-
include/linux/wl12xx.h | 22 +-
6 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 28133d5..bf06d95 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -540,7 +540,7 @@ static struct spi_board_info omap3pandora_spi_board_info[]
__initdata = {
static void __init pandora_wl1251_init(void)
{
- struct wl12xx_platform_data pandora_wl1251_pdata;
+ struct wl1251_platform_data pandora_wl1251_pdata;
int ret;
memset(pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -554,7 +554,7 @@ static void __init pandora_wl1251_init(void)
goto fail_irq;
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(pandora_wl1251_pdata);
+ ret = wl1251_set_platform_data(pandora_wl1251_pdata);
if (ret 0)
goto fail_irq;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 18ca61e..733f3f2 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -80,7 +80,7 @@ enum {
RX51_SPI_MIPID, /* LCD panel */
};
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
static struct tsc2005_platform_data tsc2005_pdata;
#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c
b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
#include linux/err.h
#include linux/wl12xx.h
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
- if (platform_data)
+ if (wl12xx_platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
- platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!platform_data)
+ wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl12xx_platform_data)
return -ENOMEM;
return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct
wl12xx_platform_data *data)
struct wl12xx_platform_data *wl12xx_get_platform_data(void)
{
- if (!platform_data)
+ if (!wl12xx_platform_data)
return ERR_PTR(-ENODEV);
- return platform_data;
+ return wl12xx_platform_data;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+ if (wl1251_platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl1251_platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+ if (!wl1251_platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c
b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
struct wl1251 *wl;
struct ieee80211_hw *hw;
struct wl1251_sdio *wl_sdio;
- const struct wl12xx_platform_data *wl12xx_board_data;
+ const struct wl1251_platform_data *wl1251_board_data;
hw = wl1251_alloc_hw();
if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl-if_priv = wl_sdio;
wl-if_ops = wl1251_sdio_ops;
- wl12xx_board_data = wl12xx_get_platform_data();
- if (!IS_ERR(wl12xx_board_data)) {
- wl-set_power = wl12xx_board_data-set_power;
-
[PATCH v3 5/8] wlcore: add initial device tree support to the sdio module
If platform data is not available, try to get the required information
from the device tree. Register an OF match table and parse the
appropriate device tree nodes.
Parse interrupt property only, for now.
Signed-off-by: Luciano Coelho coe...@ti.com
---
drivers/net/wireless/ti/wlcore/sdio.c | 69 ++---
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 4c7e8ac..9370d7e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -30,7 +30,7 @@
#include linux/mmc/sdio_ids.h
#include linux/mmc/card.h
#include linux/mmc/host.h
-#include linux/gpio.h
+#include linux/of_irq.h
#include linux/wl12xx.h
#include linux/pm_runtime.h
#include linux/printk.h
@@ -214,6 +214,43 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
+{
+ struct wl12xx_platform_data *pdata;
+ struct device_node *np = dev-of_node;
+
+ if (!np) {
+ np = of_find_matching_node(NULL, dev-driver-of_match_table);
+ if (!np) {
+ dev_notice(dev, device tree node not available\n);
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(dev, can't allocate platform data\n);
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+
+ pdata-irq = irq_of_parse_and_map(np, 0);
+ if (pdata-irq 0) {
+ dev_err(dev, can't get interrupt gpio from the device tree\n);
+ goto out_free;
+ }
+
+ goto out;
+
+out_free:
+ kfree(pdata);
+ pdata = ERR_PTR(-ENODEV);
+
+out:
+ return pdata;
+}
+
static int wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
@@ -248,11 +285,22 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ /* The pdata allocated here is freed when the device is freed,
+* so we don't need an additional out label to free it in case
+* of error further on.
+*/
+
+ /* Try to get legacy platform data from the board file */
pdev_data-pdata = wl12xx_get_platform_data();
if (IS_ERR(pdev_data-pdata)) {
- ret = PTR_ERR(pdev_data-pdata);
- dev_err(glue-dev, missing wlan platform data: %d\n, ret);
- goto out_free_glue;
+ dev_info(func-dev,
+legacy platform data not found, trying device
tree\n);
+
+ pdev_data-pdata = wlcore_get_pdata_from_of(func-dev);
+ if (IS_ERR(pdev_data-pdata)) {
+ dev_err(func-dev, can't get platform data\n);
+ goto out_free_glue;
+ }
}
/* if sdio can keep power while host is suspended, enable wow */
@@ -386,16 +434,25 @@ static const struct dev_pm_ops wl1271_sdio_pm_ops = {
};
#endif
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+ { .compatible = ti,wilink6 },
+ { .compatible = ti,wilink7 },
+ { .compatible = ti,wilink8 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, wlcore_sdio_of_match_table);
+
static struct sdio_driver wl1271_sdio_driver = {
.name = wl1271_sdio,
.id_table = wl1271_devices,
.probe = wl1271_probe,
.remove = wl1271_remove,
-#ifdef CONFIG_PM
.drv = {
+#ifdef CONFIG_PM
.pm = wl1271_sdio_pm_ops,
- },
#endif
+ .of_match_table = of_match_ptr(wlcore_sdio_of_match_table),
+ },
};
static int __init wl1271_init(void)
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 4/8] wl12xx: use frequency instead of enumerations for pdata clocks
Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead. Also add a
boolean to specify whether the clock is XTAL or not.
Change all board files to reflect this.
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c |3 +-
arch/arm/mach-omap2/board-4430sdp.c |5 ++-
arch/arm/mach-omap2/board-omap3evm.c |3 +-
arch/arm/mach-omap2/board-omap4panda.c |3 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |3 +-
drivers/net/wireless/ti/wl12xx/main.c| 57 +-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +
include/linux/wl12xx.h | 27 ++--
8 files changed, 97 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 544b6fa..eddced8 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,7 +1377,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
- .board_ref_clock= WL12XX_REFCLOCK_38,
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 953f620..0d3cb10 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -693,8 +693,9 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
}
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_26,
- .board_tcxo_clock = WL12XX_TCXOCLOCK_26,
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
+ .tcxo_clock_freq = 2600,
};
static void __init omap4_sdp4430_wifi_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8abce3cd..8f953ed 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -458,7 +458,8 @@ static struct platform_device omap3evm_wlan_regulator = {
};
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
#endif
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5b33626..b90fd4c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -230,7 +230,8 @@ static struct platform_device omap_vwlan_device = {
};
static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static struct twl6040_codec_data twl6040_codec = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 4f84cf9..83a9a36 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,7 +244,8 @@ static struct platform_device *zoom_devices[] __initdata = {
};
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
};
static struct omap2_hsmmc_info mmc[] = {
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..216c2fd 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,42 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static const struct wl12xx_clock wl12xx_refclock_table[] = {
+ { 1920, false, WL12XX_REFCLOCK_19 },
+ { 2600, false, WL12XX_REFCLOCK_26 },
+ { 2600, true, WL12XX_REFCLOCK_26_XTAL },
+ { 3840, false, WL12XX_REFCLOCK_38 },
+ { 3840, true, WL12XX_REFCLOCK_38_XTAL },
+ { 5200, false, WL12XX_REFCLOCK_52 },
+ { 0,false, 0 }
+};
+
+static const struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+ { 16368000, true, WL12XX_TCXOCLOCK_16_368 },
+ { 1680, true, WL12XX_TCXOCLOCK_16_8 },
+ { 1920, true, WL12XX_TCXOCLOCK_19_2 },
+ { 2600, true, WL12XX_TCXOCLOCK_26 },
+ { 32736000, true, WL12XX_TCXOCLOCK_32_736 },
+ { 3360, true, WL12XX_TCXOCLOCK_33_6 },
+ { 3840, true, WL12XX_TCXOCLOCK_38_4 },
+ { 5200,
[PATCH v3 3/8] wlcore: remove pwr_in_suspend from platform data
The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure. Move it to the platform device data that
is passed from SDIO to wlcore.
Signed-off-by: Luciano Coelho coe...@ti.com
---
drivers/net/wireless/ti/wlcore/main.c |2 +-
drivers/net/wireless/ti/wlcore/sdio.c |2 +-
drivers/net/wireless/ti/wlcore/wlcore_i.h |1 +
include/linux/wl12xx.h|1 -
4 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index 7b5d0cc..aada037 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5952,7 +5952,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
if (!ret) {
wl-irq_wake_enabled = true;
device_init_wakeup(wl-dev, 1);
- if (pdata-pwr_in_suspend)
+ if (pdev_data-pwr_in_suspend)
wl-hw-wiphy-wowlan = wlcore_wowlan_support;
}
#endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
dev_dbg(glue-dev, sdio PM caps = 0x%x\n, mmcflags);
if (mmcflags MMC_PM_KEEP_POWER)
- pdev_data-pdata-pwr_in_suspend = true;
+ pdev_data-pwr_in_suspend = true;
sdio_set_drvdata(func, glue);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h
b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
struct wlcore_platdev_data {
struct wl12xx_platform_data *pdata;
struct wl1271_if_operations *if_ops;
+ bool pwr_in_suspend;
};
#define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 1bfcd19..ab90b1c 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -59,7 +59,6 @@ struct wl12xx_platform_data {
int irq;
int board_ref_clock;
int board_tcxo_clock;
- bool pwr_in_suspend;
};
#ifdef CONFIG_WILINK_PLATFORM_DATA
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 8/8] wlcore/wl12xx: check if we got correct clock data from DT
The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values. WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error. WiLink7 needs both clocks, if either is not available we
return with an error.
Signed-off-by: Luciano Coelho coe...@ti.com
---
drivers/net/wireless/ti/wl12xx/main.c | 20 +---
drivers/net/wireless/ti/wlcore/sdio.c |4
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 216c2fd..1be0b51 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int
*selected_clock)
u16 sys_clk_cfg;
int ret;
+ if ((priv-ref_clock 0) || (priv-tcxo_clock 0)) {
+ wl1271_error(Missing fref and/or tcxo clock settings\n);
+ return -EINVAL;
+ }
+
/* For XTAL-only modes, FREF will be used after switching from TCXO */
if (priv-ref_clock == WL12XX_REFCLOCK_26_XTAL ||
priv-ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
u32 clk;
int ret;
+ if (priv-ref_clock 0) {
+ wl1271_error(Missing fref clock settings\n);
+ return -EINVAL;
+ }
+
if (WL127X_PG_GET_MAJOR(wl-hw_pg_ver) 3)
wl-quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
@@ -1757,7 +1767,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, wl12xx_ht_cap);
wl12xx_conf_init(wl);
- if (!fref_param) {
+ if (!fref_param (pdata-ref_clock_freq 0)) {
priv-ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
pdata-ref_clock_freq,
pdata-ref_clock_xtal);
@@ -1768,6 +1778,8 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv-ref_clock;
}
+ } else if (!fref_param) {
+ priv-ref_clock = -EINVAL;
} else {
if (!strcmp(fref_param, 19.2))
priv-ref_clock = WL12XX_REFCLOCK_19;
@@ -1785,7 +1797,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wl1271_error(Invalid fref parameter %s, fref_param);
}
- if (!tcxo_param) {
+ if (!fref_param (pdata-tcxo_clock_freq 0)) {
priv-tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
pdata-tcxo_clock_freq,
true);
@@ -1795,7 +1807,9 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv-tcxo_clock;
}
- } else {
+ } else if (!fref_param) {
+ priv-tcxo_clock = -EINVAL;
+ }else {
if (!strcmp(tcxo_param, 19.2))
priv-tcxo_clock = WL12XX_TCXOCLOCK_19_2;
else if (!strcmp(tcxo_param, 26))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
- /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
glue-refclock = of_clk_get_by_name(np, refclock);
if (IS_ERR(glue-refclock)) {
- dev_err(dev, couldn't find refclock on the device tree\n);
glue-refclock = NULL;
} else {
clk_prepare_enable(glue-refclock);
pdata-ref_clock_freq = clk_get_rate(glue-refclock);
}
- /* TODO: make sure we have this when needed (ie. for WL7) */
glue-tcxoclock = of_clk_get_by_name(np, tcxoclock);
if (IS_ERR(glue-tcxoclock)) {
- dev_err(dev, couldn't find tcxoclock on the device tree\n);
glue-tcxoclock = NULL;
} else {
clk_prepare_enable(glue-tcxoclock);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 6/8] wlcore: sdio: add wilink clock providers
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/wireless/ti/wlcore/sdio.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 9370d7e..980bf3d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
#include linux/wl12xx.h
#include linux/pm_runtime.h
#include linux/printk.h
+#include linux/clk-provider.h
#include wlcore.h
#include wl12xx_80211.h
@@ -214,10 +215,15 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = ti,wilink-clock },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev-of_node;
+ struct device_node *clock_node;
if (!np) {
np = of_find_matching_node(NULL, dev-driver-of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
+
goto out;
out_free:
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 7/8] wlcore: sdio: get clocks from device tree
Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.
Also, call sdio_set_drvdata() earlier, so the glue is already set in
the driver data when we call wlcore_get_pdata_from_of() and we don't
need to pass it as a parameter.
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/wireless/ti/wlcore/sdio.c | 36 +++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 980bf3d..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -53,6 +53,7 @@ static bool dump = false;
struct wl12xx_sdio_glue {
struct device *dev;
struct platform_device *core;
+ struct clk *refclock, *tcxoclock;
};
static const struct sdio_device_id wl1271_devices[] = {
@@ -224,6 +225,7 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
struct wl12xx_platform_data *pdata;
struct device_node *np = dev-of_node;
struct device_node *clock_node;
+ struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
if (!np) {
np = of_find_matching_node(NULL, dev-driver-of_match_table);
@@ -250,6 +252,26 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
+ /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
+ glue-refclock = of_clk_get_by_name(np, refclock);
+ if (IS_ERR(glue-refclock)) {
+ dev_err(dev, couldn't find refclock on the device tree\n);
+ glue-refclock = NULL;
+ } else {
+ clk_prepare_enable(glue-refclock);
+ pdata-ref_clock_freq = clk_get_rate(glue-refclock);
+ }
+
+ /* TODO: make sure we have this when needed (ie. for WL7) */
+ glue-tcxoclock = of_clk_get_by_name(np, tcxoclock);
+ if (IS_ERR(glue-tcxoclock)) {
+ dev_err(dev, couldn't find tcxoclock on the device tree\n);
+ glue-tcxoclock = NULL;
+ } else {
+ clk_prepare_enable(glue-tcxoclock);
+ pdata-ref_clock_freq = clk_get_rate(glue-tcxoclock);
+ }
+
goto out;
out_free:
@@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ sdio_set_drvdata(func, glue);
+
/* The pdata allocated here is freed when the device is freed,
* so we don't need an additional out label to free it in case
* of error further on.
@@ -319,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
if (mmcflags MMC_PM_KEEP_POWER)
pdev_data-pwr_in_suspend = true;
- sdio_set_drvdata(func, glue);
-
/* Tell PM core that we don't need the card to be powered now */
pm_runtime_put_noidle(func-dev);
@@ -387,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
{
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+ if (glue-refclock) {
+ clk_disable_unprepare(glue-refclock);
+ clk_put(glue-refclock);
+ }
+
+ if (glue-tcxoclock) {
+ clk_disable_unprepare(glue-tcxoclock);
+ clk_put(glue-tcxoclock);
+ }
+
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Fix address decoding on Bimini and js2x machines
On 07/03/2013 01:01 AM, Benjamin Herrenschmidt wrote:
Commit:
e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7
of/address: Handle #address-cells 2 specially
broke real time clock access on Bimini, js2x, and similar powerpc
machines using the maple platform. That code was indirectly relying
on the old (broken) behaviour of the translation for the hypertransport
to ISA bridge.
This fixes it by treating hypertransport as a PCI bus
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: sta...@vger.kernel.org [v3.6+]
---
Rob, if you have no objection I will put that in powerpc -next
NP.
Acked-by: Rob Herring rob.herr...@calxeda.com
Rob
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 04da786..7c8221d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -106,8 +106,12 @@ static unsigned int of_bus_default_get_flags(const
__be32 *
static int of_bus_pci_match(struct device_node *np)
{
- /* vci is for the /chaos bridge on 1st-gen PCI powermacs */
- return !strcmp(np-type, pci) || !strcmp(np-type, vci);
+ /*
+* vci is for the /chaos bridge on 1st-gen PCI powermacs
+* ht is hypertransport
+*/
+ return !strcmp(np-type, pci) || !strcmp(np-type, vci) ||
+ !strcmp(np-type, ht);
}
static void of_bus_pci_count_cells(struct device_node *np,
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/8] wl1251: split wl251 platform data to a separate structure
On Wed, Jul 03, 2013 at 05:03:22PM +0300, Luciano Coelho wrote: Move the wl1251 part of the wl12xx platform data structure into a new structure specifically for wl1251. Change the platform data built-in block and board files accordingly. Cc: Tony Lindgren t...@atomide.com Signed-off-by: Luciano Coelho coe...@ti.com Acked-by: Tony Lindgren t...@atomide.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
Hi,
On Wed, Jul 03, 2013 at 05:03:23PM +0300, Luciano Coelho wrote:
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..953f620 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
omap4_sdp4430_wifi_mux_init();
omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, GPIO_WIFI_IRQ);
+ if (ret) {
+ pr_err(error requesting wl12xx gpio: %d\n, ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err(error setting wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
if (ret)
pr_err(Error setting wl12xx data: %d\n, ret);
+
ret = platform_device_register(omap_vwlan_device);
if (ret)
pr_err(Error registering wl12xx device: %d\n, ret);
+out:
+ return;
+free:
+ gpio_free(GPIO_WIFI_IRQ);
actually, you should leave this GPIO requested in order to use it as
IRQ.
ditto for all others
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization. This will be more
meaningful than driver-specific quirks when we switch to DT.
Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
[...]
@@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw,
void *context)
wlcore_adjust_conf(wl);
wl-irq = platform_get_irq(pdev, 0);
- wl-platform_quirks = pdata-platform_quirks;
wl-if_ops = pdev_data-if_ops;
- if (wl-platform_quirks WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
- irqflags = IRQF_TRIGGER_RISING;
- else
- irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+ irq_data = irq_get_irq_data(wl-irq);
+ if (!irq_data) {
+ wl1271_error(couldn't get irq data for irq %d\n, wl-irq);
+ ret = -EINVAL;
+ goto out_free_nvs;
+ }
+
+ wl-irq_flags = irqd_get_trigger_type(irq_data);
BTW, there seems to be a patch on its way to make reading the flags
easier (ie. no need to get the irq_data first):
http://mid.gmane.org/1367945288-5625-1-git-send-email-jav...@dowhile0.org
I'm not sure if this is going to be taken in, but if it does, it would
be nice to change the code here to use the new irq_get_trigger_type()
function.
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 4/8] wl12xx: use frequency instead of enumerations for pdata clocks
On Wed, Jul 03, 2013 at 05:03:25PM +0300, Luciano Coelho wrote: Instead of defining an enumeration with the FW specific values for the different clock rates, use the actual frequency instead. Also add a boolean to specify whether the clock is XTAL or not. Change all board files to reflect this. Cc: Tony Lindgren t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, 2013-07-03 at 17:13 +0300, Felipe Balbi wrote:
Hi,
On Wed, Jul 03, 2013 at 05:03:23PM +0300, Luciano Coelho wrote:
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..953f620 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
omap4_sdp4430_wifi_mux_init();
omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, GPIO_WIFI_IRQ);
+ if (ret) {
+ pr_err(error requesting wl12xx gpio: %d\n, ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err(error setting wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
if (ret)
pr_err(Error setting wl12xx data: %d\n, ret);
+
ret = platform_device_register(omap_vwlan_device);
if (ret)
pr_err(Error registering wl12xx device: %d\n, ret);
+out:
+ return;
+free:
+ gpio_free(GPIO_WIFI_IRQ);
actually, you should leave this GPIO requested in order to use it as
IRQ.
ditto for all others
Actually, I don't need to use the GPIO if something goes wrong (ie.
setting the IRQ type or setting the platform data). Notice that in the
normal cases (ie. without errors), I return before the gpio_free() is
called.
This is not really needed, but it's a bit cleaner and we can probably
release some resources.
--
Luca.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 5/8] wlcore: add initial device tree support to the sdio module
On Wed, Jul 03, 2013 at 05:03:26PM +0300, Luciano Coelho wrote: If platform data is not available, try to get the required information from the device tree. Register an OF match table and parse the appropriate device tree nodes. Parse interrupt property only, for now. Signed-off-by: Luciano Coelho coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 8/8] wlcore/wl12xx: check if we got correct clock data from DT
On Wed, Jul 03, 2013 at 05:03:29PM +0300, Luciano Coelho wrote: The fref and the tcxo clocks settings are optional in some platforms. WiLink8 doesn't need either, so we don't check the values. WiLink 6 only needs the fref clock, so we check that it is valid or return with an error. WiLink7 needs both clocks, if either is not available we return with an error. Signed-off-by: Luciano Coelho coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 3/8] wlcore: remove pwr_in_suspend from platform data
On Wed, Jul 03, 2013 at 05:03:24PM +0300, Luciano Coelho wrote: The pwr_in_suspend flag depends on the MMC settings which can be retrieved from the SDIO subsystem, so it doesn't need to be part of the platform data structure. Move it to the platform device data that is passed from SDIO to wlcore. Signed-off-by: Luciano Coelho coe...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, Jul 03, 2013 at 05:18:14PM +0300, Luciano Coelho wrote:
On Wed, 2013-07-03 at 17:13 +0300, Felipe Balbi wrote:
Hi,
On Wed, Jul 03, 2013 at 05:03:23PM +0300, Luciano Coelho wrote:
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56a9a4f..953f620 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -703,12 +703,30 @@ static void __init omap4_sdp4430_wifi_init(void)
omap4_sdp4430_wifi_mux_init();
omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
+
+ ret = gpio_request_one(GPIO_WIFI_IRQ, GPIOF_IN, GPIO_WIFI_IRQ);
+ if (ret) {
+ pr_err(error requesting wl12xx gpio: %d\n, ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(GPIO_WIFI_IRQ), IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err(error setting wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
if (ret)
pr_err(Error setting wl12xx data: %d\n, ret);
+
ret = platform_device_register(omap_vwlan_device);
if (ret)
pr_err(Error registering wl12xx device: %d\n, ret);
+out:
+ return;
+free:
+ gpio_free(GPIO_WIFI_IRQ);
actually, you should leave this GPIO requested in order to use it as
IRQ.
ditto for all others
Actually, I don't need to use the GPIO if something goes wrong (ie.
setting the IRQ type or setting the platform data). Notice that in the
normal cases (ie. without errors), I return before the gpio_free() is
called.
hah, missed the 'return' call, my bad :-p
Reviewed-by: Felipe Balbi ba...@ti.com
Corrected-my-broken-eye-sight-by: Luciano Coelho coe...@ti.com
--
balbi
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10] i2c-designware: make SDA hold time configurable
On Wednesday 03 July 2013, Christian Ruppert wrote:
On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote:
On Wednesday 26 June 2013, Wolfram Sang wrote:
On Wed, Jun 26, 2013 at 10:55:06AM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com
Applied to for-next, thanks for keeping at it and providing lots of
useful information. Much appreciated!
Sorry, but I got a regression that I didn't find reported elsewhere
so far, even though it breaks a lot of the ARM defconfig builds:
drivers/built-in.o: In function `dw_i2c_probe':
/git/arm-soc/drivers/i2c/busses/i2c-designware-platdrv.c:125: undefined
reference to `__udivdi3'
I suspect you want something like the change below.
This looks similar to a patch Vincent Stehle submitted yesterday, see
https://lkml.org/lkml/2013/7/2/145
Thanks for the link. Actually his patch looks wrong to me, because
dev-sda_hold_time = div_u64((u64)ic_clk * ht + 50, 100);
assigns the division remainder to sda_hold_time, not the quotient.
Arnd
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index def79b5..57e3a07 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -119,10 +119,13 @@ static int dw_i2c_probe(struct platform_device *pdev)
if (pdev-dev.of_node) {
u32 ht = 0;
u32 ic_clk = dev-get_clk_rate_khz(dev);
+ u64 hold_time;
of_property_read_u32(pdev-dev.of_node,
i2c-sda-hold-time-ns, ht);
- dev-sda_hold_time = ((u64)ic_clk * ht + 50) / 100;
+ hold_time = (u64)ic_clk * ht + 50;
+ do_div(hold_time, 100);
+ dev-sda_hold_time = hold_time;
}
dev-functionality =
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Fix address decoding on Bimini and js2x machines
On Wed, Jul 3, 2013 at 3:10 PM, Rob Herring robherri...@gmail.com wrote: On 07/03/2013 01:01 AM, Benjamin Herrenschmidt wrote: Commit: e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7 of/address: Handle #address-cells 2 specially broke real time clock access on Bimini, js2x, and similar powerpc machines using the maple platform. That code was indirectly relying on the old (broken) behaviour of the translation for the hypertransport to ISA bridge. This fixes it by treating hypertransport as a PCI bus Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org CC: sta...@vger.kernel.org [v3.6+] --- Rob, if you have no objection I will put that in powerpc -next NP. Acked-by: Rob Herring rob.herr...@calxeda.com I'll include this in my 3.11 pull request for Linus g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10] i2c-designware: make SDA hold time configurable
On Wednesday 03 July 2013, Christian Ruppert wrote: On Wed, Jul 03, 2013 at 04:20:03PM +0200, Arnd Bergmann wrote: On Wednesday 03 July 2013, Christian Ruppert wrote: On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote: On Wednesday 26 June 2013, Wolfram Sang wrote: On Wed, Jun 26, 2013 at 10:55:06AM +0200, Christian Ruppert wrote: This patch makes the SDA hold time configurable through device tree. Signed-off-by: Christian Ruppert christian.rupp...@abilis.com Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com Applied to for-next, thanks for keeping at it and providing lots of useful information. Much appreciated! Sorry, but I got a regression that I didn't find reported elsewhere so far, even though it breaks a lot of the ARM defconfig builds: drivers/built-in.o: In function `dw_i2c_probe': /git/arm-soc/drivers/i2c/busses/i2c-designware-platdrv.c:125: undefined reference to `__udivdi3' I suspect you want something like the change below. This looks similar to a patch Vincent Stehle submitted yesterday, see https://lkml.org/lkml/2013/7/2/145 Thanks for the link. Actually his patch looks wrong to me, because dev-sda_hold_time = div_u64((u64)ic_clk * ht + 50, 100); assigns the division remainder to sda_hold_time, not the quotient. Hrmmm... At least when I tested it this morning on an ARC architecture it worked as intended and returned the quotient. Does that mean we have an issue with this function on ARC? Can anyone who knows these functions better than I comment? ARC just uses the generic version of div_u64, which is defined in lib/div64.c. I suspect that the division remainder just happens to work well enough for you to not cause any run-time error. You could try adding a printk in that function to show the values you get on ARC. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10] i2c-designware: make SDA hold time configurable
On Wednesday 03 July 2013, Christian Ruppert wrote: On Wed, Jul 03, 2013 at 04:20:03PM +0200, Arnd Bergmann wrote: On Wednesday 03 July 2013, Christian Ruppert wrote: On Wed, Jul 03, 2013 at 01:43:11PM +0200, Arnd Bergmann wrote: On Wednesday 26 June 2013, Wolfram Sang wrote: On Wed, Jun 26, 2013 at 10:55:06AM +0200, Christian Ruppert wrote: This patch makes the SDA hold time configurable through device tree. Signed-off-by: Christian Ruppert christian.rupp...@abilis.com Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com Applied to for-next, thanks for keeping at it and providing lots of useful information. Much appreciated! Sorry, but I got a regression that I didn't find reported elsewhere so far, even though it breaks a lot of the ARM defconfig builds: drivers/built-in.o: In function `dw_i2c_probe': /git/arm-soc/drivers/i2c/busses/i2c-designware-platdrv.c:125: undefined reference to `__udivdi3' I suspect you want something like the change below. This looks similar to a patch Vincent Stehle submitted yesterday, see https://lkml.org/lkml/2013/7/2/145 Thanks for the link. Actually his patch looks wrong to me, because dev-sda_hold_time = div_u64((u64)ic_clk * ht + 50, 100); assigns the division remainder to sda_hold_time, not the quotient. Hrmmm... At least when I tested it this morning on an ARC architecture it worked as intended and returned the quotient. Does that mean we have an issue with this function on ARC? Can anyone who knows these functions better than I comment? ARC just uses the generic version of div_u64, which is defined in lib/div64.c. I suspect that the division remainder just happens to work well enough for you to not cause any run-time error. You could try adding a printk in that function to show the values you get on ARC. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho coe...@ti.com wrote:
On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization. This will be more
meaningful than driver-specific quirks when we switch to DT.
Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
[...]
@@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware *fw,
void *context)
wlcore_adjust_conf(wl);
wl-irq = platform_get_irq(pdev, 0);
- wl-platform_quirks = pdata-platform_quirks;
wl-if_ops = pdev_data-if_ops;
- if (wl-platform_quirks WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
- irqflags = IRQF_TRIGGER_RISING;
- else
- irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+ irq_data = irq_get_irq_data(wl-irq);
+ if (!irq_data) {
+ wl1271_error(couldn't get irq data for irq %d\n, wl-irq);
+ ret = -EINVAL;
+ goto out_free_nvs;
+ }
+
+ wl-irq_flags = irqd_get_trigger_type(irq_data);
BTW, there seems to be a patch on its way to make reading the flags
easier (ie. no need to get the irq_data first):
http://mid.gmane.org/1367945288-5625-1-git-send-email-jav...@dowhile0.org
I'm not sure if this is going to be taken in, but if it does, it would
be nice to change the code here to use the new irq_get_trigger_type()
function.
--
Luca.
Hi Luca
That patch has been already merged in Linus tree as commit 1f6236bf
(genirq: Add irq_get_trigger_type() to get IRQ flags).
So yes, it would be better if you can use irq_get_trigger_type()
instead calling irq_get_irq_data() + irqd_get_trigger_type().
Best regards,
Javier
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v10] i2c-designware: make SDA hold time configurable
On Wednesday 03 July 2013, Stehle Vincent-B46079 wrote:
From: Christian Ruppert [mailto:christian.rupp...@abilis.com]
(..)
Although this doesn't explicitly state what the function returns to me
this sounds more like the quotient is returned rather than the remainder?
Hi,
Yes div_u64() returns the quotient.
It is defined in linux/math64.h as:
static inline u64 div_u64(u64 dividend, u32 divisor)
{
u32 remainder;
return div_u64_rem(dividend, divisor, remainder);
}
The remainder is probably fully optimized out.
Ah, you are right, sorry for the confusion on my part.
I thought you had used do_div() rather than div_u64().
Everything's fine then, feel free to add my
Acked-by: Arnd Bergmann a...@arndb.de
to your patch.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
2013/7/3 Richard Genoud richard.gen...@gmail.com: 2013/7/2 Bo Shen voice.s...@atmel.com: Hi Richard, On 7/2/2013 16:13, Richard Genoud wrote: Please hold on of this, as to the ASoC dmaengine will deal with this. So, we not need do it manually. Now, I am working on it. And will send out the patch soon after testing OK. Ok, I stay tuned ! I think you can go on working with the two patches I send just now. [1]: ASoC: atmel_ssc_dai: move set dma data to startup callback https://patchwork.kernel.org/patch/2811241/ [2]: ASoC: atmel-pcm: use generic dmaengine framework https://patchwork.kernel.org/patch/2811261/ I use your patches 4 ~ 8 do a quick testing, it works. Please note the name of asound.state under /etc in your rootfs should the same with atmel,model in patch 6. Thanks for testing ! I was just doing the same test, it works with aplay -Dplug:default good_music.wav but there's a violent hang (kernel stops, no trace) when I try the record : arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav last thing I see is : dma dma0chan3: atc_control (3) I'll try to trace that. I think it's DMA related. the last thing done by the kernel is: i2c i2c-0: i2c_outb: 0x34 A i2c i2c-0: i2c_outb: 0x0c A i2c i2c-0: i2c_outb: 0x5a A meaning: enable power on, LINE IN, ADC, OSC, on the WM8731 so, after that, data is comming from the codec to the SSC and then is handled by the DMA. there must be something nasty on the DMA bus to hang everything like that... Richard. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 02/10] ASoC: imx-pcm-fiq: Introduce pcm-fiq-params
On Thu, Jun 20, 2013 at 03:20:21PM +0200, Markus Pargmann wrote: Cleaner parameter passing for imx-pcm-fiq. Create a seperated fiq-params struct to pass all arguments. Applied, thanks. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 04/10] ASoC: fsl-ssi: Add support for imx-pcm-fiq
On Thu, Jun 20, 2013 at 03:20:23PM +0200, Markus Pargmann wrote: + ssi_private-use_dma = !of_property_read_bool(np, fsl,imx-fiq); + This binding should be documented. I'm not sure it really needs to be a binding, though - is it not possible for the driver to just figure out that DMA won't work automatically (for example by looking at the CODEC in use)? I'm not sure this is a good name either, it should be saying why the FIQ is needed rather than saying that we should use the FIQ. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 03/10] ASoC: fsl: Move soc_ac97_ops from imx-ssi to fsl_ssi
On Thu, Jun 20, 2013 at 03:20:22PM +0200, Markus Pargmann wrote: fsl_ssi and imx-ssi can be both enabled at the same time. To be able to add AC97 support to fsl_ssi, soc_ac97_ops have to be available to both drivers. This needs to be redone on top of the changes that went into v3.11 to support multiplatform AC'97 - it won't apply any more. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 09/10] ASoC: fsl: Move fsl-ssi binding doc to sound/
On Thu, Jun 20, 2013 at 03:20:28PM +0200, Markus Pargmann wrote: fsl-ssi was located in powerpc/fsl/ssi.txt. This is no powerpc specific device, so it should be moved to sound/ as it connects to differen audio codecs. Applied, thanks. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 01/10] ASoC: imx-pcm-dma: DT support
On Thu, Jun 20, 2013 at 03:20:20PM +0200, Markus Pargmann wrote: This patch removes the NO_DT flag. The pdev pointer may have a proper of_node with the dmas property, so we can use it to request DMA channels. Applied, thanks. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 08/10] ASoC: Add phycore-ac97-dt driver
On Thu, Jun 20, 2013 at 03:20:27PM +0200, Markus Pargmann wrote:
Notes:
Changes in v9:
- Fix blank line at end of file.
Please don't include enormous changelogs like this, they're just noise.
+config SND_SOC_PHYCORE_AC97_DT
+ bool SoC Audio support for Phytec phyCORE (and phyCARD) boards
(devicetree only)
+ depends on MACH_PCA100 || MACH_PCM043
Is there an actual dependency on the machine type? This seems wrong for
a DT driver.
+static struct snd_soc_ops imx_phycore_hifi_ops = {
+};
+
You shouldn't have this if there's nothing in it.
+static struct platform_device *imx_phycore_snd_device;
This shouldn't be a global, it should be in driver data.
+/*
+ * Pointer to AC97 reset functions for specific boards
+ */
+#if IS_ENABLED(CONFIG_MACH_PCA100)
+extern void pca100_ac97_cold_reset(struct snd_ac97 *ac97);
+extern void pca100_ac97_warm_reset(struct snd_ac97 *ac97);
+#else
+static void pca100_ac97_cold_reset(struct snd_ac97 *ac97) { }
+static void pca100_ac97_warm_reset(struct snd_ac97 *ac97) { }
+#endif
+ if (of_machine_is_compatible(phytec,imx27-pca100)) {
+ phycore_ac97_reset = pca100_ac97_cold_reset;
+ phycore_ac97_warm_reset = pca100_ac97_warm_reset;
+ } else if (of_machine_is_compatible(phytec,imx35-pcm043)) {
+ phycore_ac97_reset = pcm043_ac97_cold_reset;
+ phycore_ac97_warm_reset = pcm043_ac97_warm_reset;
+ } else {
+ dev_err(pdev-dev, Failed to set AC97 reset functions,
unknown board.\n);
+ return -EINVAL;
+ }
These functions have no reason to be anywhere except in the driver and
really you should just be specifying which pins to use there - ideally
via pinctrl but I don't think i.MX has adopted that yet.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 10/10] ASoC: fsl: Update fsl-ssi binding doc
On Thu, Jun 20, 2013 at 03:20:29PM +0200, Markus Pargmann wrote: Update the fsl-ssi bindings. DMA is no required property anymore and uses the generic DMA bindings. imx-fiq is a new alternative to DMA These updates should be done as part of the patches making the code changes - see the review comment I had earlier for an example. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] DMA: Freescale: update driver to support 8-channel DMA engine
On 07/02/2013 10:47:44 PM, Hongbo Zhang wrote: On 07/03/2013 07:13 AM, Scott Wood wrote: Wait a second -- how are we even getting into this code on these new DMA controllers? All 85xx-family DMA controllers use fsldma_chan_irq directly. Right, we are using fsldma_chan_irq, this code never run. I just see there is such code for elo/eloplus DMA controllers, so I update it for the new 8-channel DMA. That code is used for elo (e.g. mpc83xx DMA), but not eloplus. -Scott ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Best practice device tree design for display subsystems/DRM
On 07/03/13 13:32, Russell King wrote:
On Wed, Jul 03, 2013 at 12:52:37PM +0200, Sebastian Hesselbarth wrote:
But honestly, I see no way around it and it is the only way
to allow to even have the decision for one or two cards at all.
There is no way for auto-probing the users intention...
Russell,
in general, for me it is hard to find out when you are really asking
questions, use rhetorical questions or sarcasm. I am not a native
speaker, so do not take any of the below personal if I am not getting
the point of it.
It's not _just_ about the users intention - for get that, because really
it's to do with solving a much bigger question, and that question is:
How do we know when all the components are present?
By exploiting phandles passed to the supernode. That supernode is very
board specific so it is defined in a board dts and can take into account
every available/unavailable physical device.
In other words, how do we know that we have LCD0 and LCD1 connected to
the DCON, which is connected to a LCD and/or a HDMI tranceiver. How
About LCD0/LCD1 connected to DCON, you have to deal with that in the
subsystem driver, i.e. DRM driver knows about some possible DCON but
registers it only if there is a phandle to a node compatible with
marvell,armada-510-dcon passed.
About LCD (panel)/HDMI transceiver, use a (hopefully standard) property
to hook the device (LCD0 on Dove) with the node of the HDMI transmitter.
do we know that the on-board VGA DACs are wired up and to be used?
Boards not using VGA DAC (LCD1 on Dove) just disable the device_node
and do not pass the node's phandle in the supernode.
How do we know which I2C bus the VGA port is connected to, and whether
to expect an I2C bus?
Again, passing a phandle to the i2c-controller node in lcd1 node.
Please note that the pure existence of this phandle property does not
in any way imply you have to use it at all in the driver. But if you
have a driver for Dove's LCD1 and that needs to know how it can access
monitor's EDID, connect it to the i2c-controller node.
I understand that this very i2c-controller driver may not be loaded
the time DRM driver accesses it. But that is not related to DT but
driver core. Currently, I guess -EPROBEDEFER or bail out is the only
option. But from a driver POV you can still say: somebody told me
to use i2c0 for EDID, so don't blame me it is not there.
Let's look at the Cubox setup (sorry, but you _will_ have to use a
fixed-width font for this):
CPU bus
|
+-I2C -TDA998X --(HDMI)-- Display
||
| (RGB888+clock+sync)
+-LCD0 -. /
+--DCON ---(VGA)--- not wired
+-LCD1 (unused)-'
DCON can allegedly route the data from LCD0 or LCD1 to the parallel
interface which the TDA998x sits on, and/or the VGA interface. In
the case of other setups, the TDA998x may be a LCD panel.
dove.dtsi:
...
soc {
internal-regs {
...
i2c0: i2c-controller@abcd0 {
compatible = marvell,mv64xxx-i2c;
...
status = disabled;
};
lcd0: lcd-controller@82 {
compatible = marvell,armada-510-lcd;
reg = 0x82 0x1000;
status = disabled;
};
lcd1: lcd-controller@81 {
compatible = marvell,armada-510-lcd;
reg = 0x81 0x1000;
status = disabled;
};
dcon: display-controller@83 {
compatible = marvell,armada-510-dcon;
reg = 0x83 0x100;
status = disabled;
};
};
};
dove-cubox.dts:
/include/ dove.dtsi
video {
card0 {
compatible = marvell,armada-510-video,
linux,video-card;
linux,video-memory-size = 0x10;
linux,video-devices = lcd0 dcon;
};
};
dcon { status = okay; };
lcd0 {
status = okay;
clocks = si5351 0;
clock-names = extclk0;
/* pin config 0 = DUMB_RGB888 */
marvell,pin-configuration = 0;
...
linux,video-external-encoder = tda998x;
};
i2c0 {
status = okay;
tda998x: hdmi-transmitter@60 {
compatible = nxp,tda19988;
reg = 0x60;
/* pin config 18 = RGB888 */
nxp,pin-configuration = 18;
/* HPD gpio pin */
interrupt-gpios = gpio0 12;
};
si5351: programmable-pll {
/* Note: this binding already exists */
compatible = silabs,5351a-msop10;
...
#clock-cells = 1;
/* referenced as si5351 0 */
clk0: {
silabs,drive-strength = 8;
Re: [PATCH 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 07/03/2013 02:48:59 AM, Hongbo Zhang wrote: On 07/03/2013 11:53 AM, Hongbo Zhang wrote: hmm...add the devicetree-discuss@lists.ozlabs.org into list. Note that we are discussing a better naming for this new compatible property in the corresponding [PATCH 2/2], so I will resend a v2 of this patch. On 07/01/2013 11:46 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add the device tree nodes for them. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi | 90 +++ arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi | 90 +++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +- 3 files changed, 182 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-dma2-1.dtsi Scott, any comment of these two file names? There's dma2 again... How about elo3-dma-n.dtsi? -Scott ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH v4 2/2] drivers: mfd: vexpress: add Serial Power Controller (SPC) support
On Tue, Jun 18, 2013 at 11:22:13AM +0100, Lorenzo Pieralisi wrote: On Mon, Jun 17, 2013 at 06:44:51PM +0100, Olof Johansson wrote: That'll trim down the driver to a point where I think you'll find it much easier to get merged. :-) To start with I have to understand in which directory this code should live. Moving the frequency settings in clk/CPUfreq drivers should be feasible with extra DT complexity for their bindings. You shoudn't really need to change the DT bindings at all - MFD is a purely Linux construct, it doesn't affect how the hardware is constructed. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 0/3] extend stmmac DT support.
From: Srinivas KANDAGATLA srinivas.kandaga...@st.com Date: Tue, 2 Jul 2013 14:03:39 +0100 From: Srinivas Kandagatla srinivas.kandaga...@st.com Hi Peppe, Thankyou for the comments on RFC patches. This patch series adds support to new gmac versions 3.6.10 and 3.710, these versions of IP are integrated into ST STiH415/STiH416 SOCs. This patchset also adds phy reset capablity to stmmac-mdio driver via DT. Changes since RFC: - re-use existing compatible strings to select right properties. - clean up reset callback support so that DT is not parsed everytime. You are going to have to fix up the following build warnings and resubmit: CC [M] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c: In function ‘stmmac_mdio_reset’: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:137:17: warning: unused variable ‘dev’ [-Wunused-variable] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c: In function ‘stmmac_mdio_register’: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:200:17: warning: unused variable ‘dev’ [-Wunused-variable] Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 01/13] misc: atmel_ssc: add device tree DMA support
Hi Richard, On 7/3/2013 23:51, Richard Genoud wrote: but there's a violent hang (kernel stops, no trace) when I try the record : arecord -v -V stereo -Dplug:default -f cd -t wav -c 2 /tmp/toto.wav last thing I see is : dma dma0chan3: atc_control (3) I don't meet this issue. Playback and recording works well on my side on at91sam9g35ek board. I'll try to trace that. I think it's DMA related. the last thing done by the kernel is: i2c i2c-0: i2c_outb: 0x34 A i2c i2c-0: i2c_outb: 0x0c A i2c i2c-0: i2c_outb: 0x5a A meaning: enable power on, LINE IN, ADC, OSC, on the WM8731 so, after that, data is comming from the codec to the SSC and then is handled by the DMA. there must be something nasty on the DMA bus to hang everything like that... Will you try i2c without DMA support to test this issue? Richard. Best Regards, Bo Shen ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH dtc] Makefile: provide separate install targets
Currently `make install` will install the binaries, libraries and includes. This change separates the install target into install-bin, install-lib and install-includes, so we have more flexibility, particularly when we're just using libfdt. Signed-off-by: Jeremy Kerr j...@ozlabs.org --- Makefile | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 1169e6c..e64bf6b 100644 --- a/Makefile +++ b/Makefile @@ -160,18 +160,26 @@ endif # intermediate target and building them again for real .SECONDARY: $(DTC_GEN_SRCS) $(CONVERT_GEN_SRCS) -install: all $(SCRIPTS) - @$(VECHO) INSTALL +install-bin: all $(SCRIPTS) + @$(VECHO) INSTALL-BIN $(INSTALL) -d $(DESTDIR)$(BINDIR) $(INSTALL) $(BIN) $(SCRIPTS) $(DESTDIR)$(BINDIR) + +install-lib: all + @$(VECHO) INSTALL-LIB $(INSTALL) -d $(DESTDIR)$(LIBDIR) $(INSTALL) $(LIBFDT_lib) $(DESTDIR)$(LIBDIR) ln -sf $(notdir $(LIBFDT_lib)) $(DESTDIR)$(LIBDIR)/$(LIBFDT_soname) ln -sf $(LIBFDT_soname) $(DESTDIR)$(LIBDIR)/libfdt.$(SHAREDLIB_EXT) $(INSTALL) -m 644 $(LIBFDT_archive) $(DESTDIR)$(LIBDIR) + +install-includes: + @$(VECHO) INSTALL-INC $(INSTALL) -d $(DESTDIR)$(INCLUDEDIR) $(INSTALL) -m 644 $(LIBFDT_include) $(DESTDIR)$(INCLUDEDIR) +install: install-bin install-lib install-includes + $(VERSION_FILE): Makefile FORCE $(call filechk,version) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Best practice device tree design for display subsystems/DRM
-Original Message-
From: Russell King [mailto:r...@arm.linux.org.uk]
Sent: Wednesday, July 03, 2013 9:05 PM
To: Inki Dae
Cc: 'Sebastian Hesselbarth'; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-
Francois Moine'; devicetree-discuss@lists.ozlabs.org; dri-
de...@lists.freedesktop.org
Subject: Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 08:43:20PM +0900, Inki Dae wrote:
In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or
lcd0
and lcd1 drivers which are placed in drivers/video/backlight/.
No, that's totally wrong. Framebuffer drivers are not backlights.
Framebuffer drivers go in drivers/video not drivers/video/backlight.
Really not that mean. Framebuffer driver controls DCON, and lcd panel driver
controls lcd0 or lcd1. Maybe there is *wrong use of sentence* . Sorry about
it.
And let's assume the following:
On board A
Display controller - lcd 0
On board B
Display controller - lcd 1
On board C
Display controller - lcd 0 and lcd 1
Without the super node, user could configure Linux kernel through
menuconfig
like below;
board A: enabling lcd 0, and disabling lcd 1,
board B: disabling lcd 0, and enabling lcd 1,
board C: enabling lcd 0 and lcd 1.
I don't think so. By using menuconfig, you completely miss the point of
using DT - which is to allow us to have a single kernel image which can
support multiple boards with different configurations, even different
SoCs.
All we have to do is to configure menuconfig to enable only drivers for
certain board. Why does fbdev need the super node? Please give me
comments
if there is my missing point.
fbdev needs the supernode _OR_ some way to specify that information which
you're putting into menuconfig, because what's correct for the way one
board is physically wired is not correct for how another board is
physically wired.
With that information in menuconfig, you get a kernel image which can
support board A, or board B, or board C but not a single kernel image
which can support board A and board B and board C by loading that very
same kernel image onto all three boards with just a different DT image.
This is the *whole* point of ARM moving over to DT.
If we wanted to use menuconfig to sort these kinds of board specific
details, we wouldn't be investing so much time and effort into moving
over to DT for ARM. In fact, we used to use menuconfig to sort out
some of these kinds of details, and we've firmly decided that this is
the wrong approach.
Today, there is a very strong push towards having a single kernel image
which runs on every (modern) ARM board with DT describing not only the
board level hardware but also the internal SoC as well.
Dear Russell. I understand what you try to do and that's true. Please see
the below in addition,
dove.dtsi:
...
soc {
internal-regs {
...
lcd0: lcd-controller@82 {
compatible = marvell,armada-510-lcd;
reg = 0x82 0x1000;
status = disabled;
};
lcd1: lcd-controller@81 {
compatible = marvell,armada-510-lcd;
reg = 0x81 0x1000;
status = disabled;
};
dcon: display-controller@83 {
compatible = marvell,armada-510-dcon;
reg = 0x83 0x100;
status = disabled;
};
};
};
Board A.dts:
/include/ dove.dtsi
dcon: display-controller@83 {
compatible = marvell,armada-510-video,
linux,video-card;
linux,video-memory-size = 0x10;
linux,video-devices = lcd0 dcon;
};
...
Board B.dts:
/include/ dove.dtsi
dcon: display-controller@83 {
compatible = marvell,armada-510-video,
linux,video-card;
linux,video-memory-size = 0x10;
linux,video-devices = lcd1 dcon;
};
...
Board C.dts:
/include/ dove.dtsi
dcon: display-controller@83 {
compatible = marvell,armada-510-video,
linux,video-card;
linux,video-memory-size = 0x10;
linux,video-devices = lcd0 lcd1 dcon;
};
...
Like above, board specific dts files could have their own board specific
information. So I think we can do and are already doing what you try to do
without the super node. The super node don't really mean real hardware.
Thanks,
Inki Dae
The OLPC setup (which seems to be the more common case in terms of the
on-SoC device structure):
CPU bus
|
+-LCD ---(RGB666+clock+sync) LCD panel
and I believe an HDMI tranceiver somewhere.
(for the sake of simplicity, I am assuming OLPC is Armada 510
aka Dove, which it isn't)
dove-olpc.dts:
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On 7/3/2013 7:33 PM, Luciano Coelho wrote: The platform_quirk element in the platform data was used to change the way the IRQ is triggered. When set, the EDGE_IRQ quirk would change the irqflags used and treat edge trigger differently from the rest. Instead of hiding this irq flag setting behind the quirk, have the board files set the flags during initialization. This will be more meaningful than driver-specific quirks when we switch to DT. Additionally, fix missing gpio_request() calls in the boarding files (so that setting the flags actually works). Cc: Tony Lindgren t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- arch/arm/mach-davinci/board-da850-evm.c |8 +- For the board-da850-evm.c change, Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 0/8] Generic PHY Framework
Hi, On Wednesday 03 July 2013 06:50 PM, Felipe Balbi wrote: Hi, On Wed, Jul 03, 2013 at 03:35:39PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 03 July 2013 03:02 PM, Patel, Satish wrote: Hi Kishon, -Original Message- From: ABRAHAM, KISHON VIJAY Sent: Wednesday, June 26, 2013 5:17 PM To: grant.lik...@linaro.org; t...@atomide.com; Balbi, Felipe; ABRAHAM, KISHON VIJAY; a...@arndb.de; swar...@nvidia.com; sylvester.nawro...@gmail.com; linux-ker...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- u...@vger.kernel.org; gre...@linuxfoundation.org; akpm@linux- foundation.org Cc: rob.herr...@calxeda.com; r...@landley.net; li...@arm.linux.org.uk; benoit.cous...@linaro.org; mche...@redhat.com; ces...@cesarb.net; da...@davemloft.net; Nayak, Rajendra; shawn@linaro.org; Shilimkar, Santosh; devicetree-discuss@lists.ozlabs.org; linux- d...@vger.kernel.org; Nori, Sekhar; Krishnamoorthy, Balaji T; Cherian, George Subject: [PATCH v9 0/8] Generic PHY Framework Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. I would like to use this framework for a smart-card controller connected to a smart-card phy. I have some questions and would like to get feedback on the same. glad to know that :-) I am using “TDA8026 Smartcard PHY from NXP. Here is the link for datasheet and app note for the same. The smart card controller is inside the TI SoC I am working with. Datasheet : www.nxp.com/documents/data_sheet/TDA8026.pdf? Appnote : http://www.nxp.com/documents/application_note/AN10724.pdf The TI SoC details are not public (yet). I can provide details to you offline. Brief about operation: - The controller can work with and without a PHY - When not using PHY, it is limited to talking to a single smart card. There is also a need to put external de-activation logic on card removal for this case. - With a PHY you can use more than one smart card. - Phy has 5 slots : 1 for smart card (credit/debit/other card with chip) and others for SAM – SIM like modules - Once the PHY is initialized, there are some operations that the controller can request of the PHY like: - Card configurations - set voltage - Activation of card - ATR – Answer to reset - Warm reset - ADPU exchange - Deactivation ( Normal/Emergency) hmm.. We should think about extending the phy_ops to include these operations (something like phy_smart_card_ops so that other smart_card PHYs will also be able to use it). let's try to avoid use-case specific additions. set_voltage sounds like a regulator thing, but the regulator is controlled through the PHY. I guess it makes sense to have a generic phy_set_voltage() call since even USB can make use of that. For card activation, it sounds like phy_init()/phy_shutdown() would cover it. For warm reset perhaps a phy_reset() callback ? Although that could, easily, get abused. For deactivation, that's phy_shutdown(). ATR and ADPU needs more thought, I guess. - In the mode when smartcard controller talks directly to the card without the need for a PHY, all the above operations will be carried out by the controller itself My current thought process is to make the controller driver provide the user interface and talk to the PHY using the generic PHY framework you proposed. In the case where there is no PHY, my idea is to create a dummy PHY which uses the controller functionality itself. right. And in the case where you actually have a PHY, create a PHY driver and implement the phy_smart_card_ops and register with the PHY framework. I would try to avoid that. Otherwise we will have phy_usb_ops, phy_sata_ops, phy_network_ops, phy_pci_ops, etc etc etc. It would easily blow up. true. But it's certainly going to be difficult to map certain function specific ops to the generic ops (just like ATR and ADPU in smart card case or set pixel for hdmi). Thanks Kishon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
