Re: [PATCH 1/1] of/irq: store IRQ trigger/level in struct resource flags
On 00:26 Thu 06 Jun , Grant Likely wrote: On Tue, 09 Apr 2013 00:44:05 +0200, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: On 04/09/2013 12:05 AM, Rob Herring wrote: On 04/05/2013 02:48 AM, Javier Martinez Canillas wrote: This means that drivers that need the IRQ type/level flags defined in the DT won't be able to get it. But the interrupt controllers that need the information should be able to get to it via irqd_get_trigger_type. What problem exactly are you trying to fix? What driver would use this? Yes but this is not about the interrupt controller wanting this information but a device driver that is using the IORESOURCE_IRQ struct resource that has the information about the virtual IRQ associated with a GPIO-IRQ. The driver doesn't know neither care if its IRQ line is connected to a line of an real IRQ controller or to a GPIO controller that allows a GPIO line to be used as an IRQ. My understanding of the IORESOURCE_IRQ_xxx (and DMA) bits are they are ISA specific and therefore should not be used on non-ISA buses. Many TI OMAP2+ SoC based boards have an SMSC LAN911x/912x controller (drivers/net/ethernet/smsc/smsc911x.c) that is connected to the OMAP processor through its General-Purpose Memory Controller (GPMC) and this LAN driver obtain its IRQ and I/O address space from a struct resource IORESOURCE_IRQ and IORESOURCE_MEM respectively, that is filled by the DeviceTree core. It does this: irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); irq_flags = irq_res-flags IRQF_TRIGGER_MASK; Since of_irq_to_resource() doesn't fill the trigger/level flags on the IORESOURCE_IRQ struct resource, irq_flags will always be 0 regarding the value specified on the second cell of the interrupts DT property. why do you need to known this in you driver this need to be handle in the irq chip I does use irq gpio without at all Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
On 08:29 Thu 16 May , Eduardo Valentin wrote:
On 15-05-2013 12:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:36 Wed 15 May , Eduardo Valentin wrote:
On 15-05-2013 11:23, Benoit Cousson wrote:
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi
b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..e5bfbfe 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
0 55 0x4;
ti,hwmods = debugss;
};
+
+bandgap {
+reg = 0x4a002260 0x4
+0x4a00232C 0x4
+0x4a002378 0x18;
+compatible = ti,omap4460-bandgap;
+interrupts = 0 126 4; /* talert */
+ti,tshut-gpio = 86;
Why do you need a custom attribute for GPIO? Cannot you use the standard
one?
I believe it was by your suggestion :-), during the first attempts to
send this driver. But could not find the thread link :-( sorry.
I guess the reasoning to mark it as a ti specific is because it will be
used as IRQ line to treat thermal shutdown (in SW).
so use interrup-parent
Jean-Christophe,
That will change the controller and break the configuration for the
other IRQ line, coming from GIC.
put this on hold I'm preparing a fix for this
I've discuss with Grant already.
This way for me is buggy
Best Regards,
J.
Where is the gpio controller phandle?
Usually it looks like this:
gpios = gpio1 8 0;
Regards,
Benoit
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/32] OMAPDSS: DPI: fix regulators for DT
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the virtual omapdss device is not present there.
Fix the issue by acquiring the regulator in the DPI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to DPI.
as discuss with Arnd we should handle regular enable and disable at device
probe for every device as we do for pinctrl
Best Regards,
J.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index ef8fca2..43f6b26 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -37,7 +37,10 @@
#include dss_features.h
static struct {
+ struct platform_device *pdev;
+
struct regulator *vdds_dsi_reg;
+ bool vdds_dsi_from_core;
struct platform_device *dsidev;
struct mutex lock;
@@ -583,10 +586,15 @@ static int dpi_init_display(struct omap_dss_device
*dssdev)
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
-
if (IS_ERR(vdds_dsi)) {
- DSSERR(can't get VDDS_DSI regulator\n);
- return PTR_ERR(vdds_dsi);
+ vdds_dsi = regulator_get(dpi.pdev-dev, vdds_dsi);
+ if (IS_ERR(vdds_dsi)) {
+ DSSERR(can't get VDDS_DSI regulator\n);
+ return PTR_ERR(vdds_dsi);
+ }
+ dpi.vdds_dsi_from_core = false;
+ } else {
+ dpi.vdds_dsi_from_core = true;
}
dpi.vdds_dsi_reg = vdds_dsi;
@@ -702,6 +710,8 @@ static int omap_dpi_probe(struct platform_device *pdev)
{
int r;
+ dpi.pdev = pdev;
+
mutex_init(dpi.lock);
dpi_init_output(pdev);
@@ -725,6 +735,11 @@ static int __exit omap_dpi_remove(struct platform_device
*pdev)
dpi_uninit_output(pdev);
+ if (dpi.vdds_dsi_reg != NULL dpi.vdds_dsi_from_core == false) {
+ regulator_put(dpi.vdds_dsi_reg);
+ dpi.vdds_dsi_reg = NULL;
+ }
+
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/32] OMAPDSS: fix dss_get_ctx_loss_count for DT
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
When using DT, dss device does not have platform data. However,
dss_get_ctx_loss_count() uses dss device's platform data to find the
get_ctx_loss_count function pointer.
To fix this, dss_get_ctx_loss_count() needs to be changed to get the
platform data from the omapdss device, which is a virtual device and
always has platform data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 94f66f9..bd01608 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -157,7 +157,8 @@ static void dss_restore_context(void)
int dss_get_ctx_loss_count(void)
{
- struct omap_dss_board_info *board_data = dss.pdev-dev.platform_data;
+ struct platform_device *core_pdev = dss_get_core_pdev();
+ struct omap_dss_board_info *board_data = core_pdev-dev.platform_data;
how about store the pdata in the drivers internal struct and if !dt
you ust do this
dss_dev-pdata = *pdev-dev.platform_data;
to copy it and we do not alloc it for dt
Best Regards,
J.
int cnt;
if (!board_data-get_context_loss_count)
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/32] OMAPDSS: add omap_dss_find_output()
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
Add a support function to find a DSS output by given name. This is used
in later patches to link the panels to DSS outputs.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/output.c | 13 +
include/video/omapdss.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/video/omap2/dss/output.c
b/drivers/video/omap2/dss/output.c
index 5214df6..3274628 100644
--- a/drivers/video/omap2/dss/output.c
+++ b/drivers/video/omap2/dss/output.c
@@ -115,6 +115,19 @@ struct omap_dss_output *omap_dss_get_output(enum
omap_dss_output_id id)
}
EXPORT_SYMBOL(omap_dss_get_output);
GPL please
+struct omap_dss_output *omap_dss_find_output(const char *name)
+{
+ struct omap_dss_output *out;
+
+ list_for_each_entry(out, output_list, list) {
+ if (strcmp(out-name, name) == 0)
+ return out;
+ }
+
+ return NULL;
+}
I this in so many drivers could we have a macro to generate such function?
+EXPORT_SYMBOL(omap_dss_find_output);
ditto GPL
Best Regards,
J.
+
static const struct dss_mgr_ops *dss_mgr_ops;
int dss_install_mgr_ops(const struct dss_mgr_ops *mgr_ops)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index d5f1fff..aad47a2 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -779,6 +779,7 @@ int omap_dss_get_num_overlays(void);
struct omap_overlay *omap_dss_get_overlay(int num);
struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id);
+struct omap_dss_output *omap_dss_find_output(const char *name);
int omapdss_output_set_device(struct omap_dss_output *out,
struct omap_dss_device *dssdev);
int omapdss_output_unset_device(struct omap_dss_output *out);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-fbdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/32] OMAPDSS: add omap_dss_find_output()
On 14:40 Thu 30 May , Tomi Valkeinen wrote:
On 30/05/13 14:07, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
Add a support function to find a DSS output by given name. This is used
in later patches to link the panels to DSS outputs.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/output.c | 13 +
include/video/omapdss.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/video/omap2/dss/output.c
b/drivers/video/omap2/dss/output.c
index 5214df6..3274628 100644
--- a/drivers/video/omap2/dss/output.c
+++ b/drivers/video/omap2/dss/output.c
@@ -115,6 +115,19 @@ struct omap_dss_output *omap_dss_get_output(enum
omap_dss_output_id id)
}
EXPORT_SYMBOL(omap_dss_get_output);
GPL please
The omapdss driver uses EXPORT_SYMBOL. I don't want to start mixing both
EXPORT_SYMBOLs and EXPORT_SYMBOL_GPLs.
I do not like EXPORT_SYMBOL at all
I stringly prefer to switch all of them to _GPL
but will not refuse the patch for this in this case
+struct omap_dss_output *omap_dss_find_output(const char *name)
+{
+ struct omap_dss_output *out;
+
+ list_for_each_entry(out, output_list, list) {
+ if (strcmp(out-name, name) == 0)
+ return out;
+ }
+
+ return NULL;
+}
I this in so many drivers could we have a macro to generate such function?
What would that help? Wouldn't it just increase the code size of the kernel?
increase no as it's not an inline function but a macro to generate the
function
after help yes but people may not like so as you wish
Best Regards,
J.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/32] OMAPDSS: fix dss_get_ctx_loss_count for DT
On 14:28 Thu 30 May , Tomi Valkeinen wrote:
On 30/05/13 14:09, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:34 Thu 30 May , Tomi Valkeinen wrote:
When using DT, dss device does not have platform data. However,
dss_get_ctx_loss_count() uses dss device's platform data to find the
get_ctx_loss_count function pointer.
To fix this, dss_get_ctx_loss_count() needs to be changed to get the
platform data from the omapdss device, which is a virtual device and
always has platform data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 94f66f9..bd01608 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -157,7 +157,8 @@ static void dss_restore_context(void)
int dss_get_ctx_loss_count(void)
{
- struct omap_dss_board_info *board_data = dss.pdev-dev.platform_data;
+ struct platform_device *core_pdev = dss_get_core_pdev();
+ struct omap_dss_board_info *board_data = core_pdev-dev.platform_data;
how about store the pdata in the drivers internal struct and if !dt
you ust do this
dss_dev-pdata = *pdev-dev.platform_data;
to copy it and we do not alloc it for dt
It's not quite that simple. We need some OMAP arch functions (like
get_ctx_loss_count here) that are not currently exposed via any other
method to drivers except passing a function pointer with platform data.
We need that also when booting with DT.
We have a bunch of devices for the display subsystem hardware blocks,
like the dss here. When booting with DT, these blocks are represented
in the DT data, and do not have platform data.
We also have a virtual device, omapdss, which doesn't match any hw
block. It's created in the arch setup stage. It's really a legacy thing,
but with DT it can be used conveniently to pass the platform data.
The problem this patch fixes is that we used to pass the arch functions
for each of those HW block drivers. But with DT, we need to get the arch
functions from the omapdss device, gotten with dss_get_core_pdev().
ok
do not take it bad is it worth the effort those 54 patches?
is not better to work on DRM?
just an open question
Best Regards,
J.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/32] OMAPDSS: DPI: fix regulators for DT
On 15:05 Thu 30 May , Arnd Bergmann wrote: On Thursday 30 May 2013, Tomi Valkeinen wrote: On 30/05/13 14:12, Jean-Christophe PLAGNIOL-VILLARD wrote: On 12:34 Thu 30 May , Tomi Valkeinen wrote: On some platforms DPI requires a regulator to be enabled to power up the output pins. This regulator is, for some reason, currently attached to the virtual omapdss device, instead of the DPI device. This does not work for DT, as the regulator mappings need to be described in the DT data, and the virtual omapdss device is not present there. Fix the issue by acquiring the regulator in the DPI device. To retain compatibility with the current board files, the old method of getting the regulator is kept. The old method can be removed when the board files have been changed to pass the regulator to DPI. as discuss with Arnd we should handle regular enable and disable at device probe for every device as we do for pinctrl I'm not sure what you mean. Enable of what? The regulator? Why would we enable it in the device's probe, as the device may never even be used? It's an idea I had a while ago, but not yet discussed in the open. Jean-Christophe just posted patches to move the mapping of interrupt numbers into platform_drv_probe(), just before calling the driver -probe() callback, and we already have similar code to set up the default pinctrl state of a device before calling probe(). This can be extended to further subsystems, but that has to be done carefully to avoid regressions. Ideally we would move a lot of boilerplate code out of the driver specific -probe() function into common code. Possible candidates for this include: * calling devm_request_mem_region for the reg property * calling devm_ioremap on the reg property * calling devm_gpio_request for all gpio lines * calling devm_regulator_get on all regulators * calling devm_reset_control_get on all reset lines * calling devm_dma_request_slave_channel on all dma channels * calling devm_of_pwm_get for all pwm channels * ... For most of these (maybe all), I think we need some form of opt-in model on the driver side because there are cases where aquiring some of these resources is not mandatory, and it only works if the driver is using DT probing. IF we want to do this, it also needs a lot of thought, and we shouldn't do it carelessly. We might also need some extra infrastructure in revres to simplify access to the resources we got from the OF node. The irq resources are particularly trivial because we already claim them in of_platform_populate, so moving that to platform_drv_probe() is straightforward and solves existing bugs without creating a huge regression potential, but it's harder for the others. Yeah I agree with Arnd we need to start to move this way but for DT only first and carefully Best Regards, J. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-fbdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
On 12:36 Wed 15 May , Eduardo Valentin wrote:
On 15-05-2013 11:23, Benoit Cousson wrote:
Hi Eduardo,
On 05/15/2013 04:58 PM, Eduardo Valentin wrote:
Include bandgap devices for OMAP4460 devices.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4460.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi
b/arch/arm/boot/dts/omap4460.dtsi
index 2cf227c..e5bfbfe 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -29,4 +29,13 @@
0 55 0x4;
ti,hwmods = debugss;
};
+
+ bandgap {
+ reg = 0x4a002260 0x4
+ 0x4a00232C 0x4
+ 0x4a002378 0x18;
+ compatible = ti,omap4460-bandgap;
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86;
Why do you need a custom attribute for GPIO? Cannot you use the standard
one?
I believe it was by your suggestion :-), during the first attempts to
send this driver. But could not find the thread link :-( sorry.
I guess the reasoning to mark it as a ti specific is because it will be
used as IRQ line to treat thermal shutdown (in SW).
so use interrup-parent
Where is the gpio controller phandle?
Usually it looks like this:
gpios = gpio1 8 0;
Regards,
Benoit
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On 21:35 Mon 07 Jan , Arnd Bergmann wrote: (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc) On Monday 07 January 2013, Tony Lindgren wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. I'm looking for this also as on at91 sama9x5ek and sam9cn12ek and the sama5d3xek, we have 1 wire eeproms to detect the boards (motherboards and daugther boards) where we have 1 1-wire per board and cpu boards so we can detect everything and have it's revision and more information we already have barebox that detect the 1-wire but we need the same handling in the kernel Best Regards, J. Arnd ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
On 17:01 Wed 30 Jan , Ruslan Bilovol wrote:
Currently, reading /proc/cpuinfo provides userspace with CPU ID of
the CPU carrying out the read from the file.
Userspace using this information may decide what module
to load or how to configure some specific (and processor-depended)
settings or so.
However, since really different SoCs can share same ARM core,
this information currently is not so useful.
For example, TI OMAP4460 and OMAP4470 SoCs show the same
information in the /proc/cpuinfo whereas they are different.
Since in most cases ARM CPU is a part of some system on a chip (SoC),
the cpuinfo file looks like exactly that place, where this
information have to be displayed.
So added new line SoC name in the cpuinfo output for system
on a chip name. It is placed between CPU information and machine
information, so the file structure looks gracefully (CPU-SoC-Hardware)
Nack
this break the kernel ABI
and we have now socinfo via sysfs
Best Regards,
J.
Example:
/ # cat proc/cpuinfo
[...]
CPU variant : 0x2
CPU part: 0xc09
CPU revision: 10
SoC name: OMAP4470
Hardware: OMAP4 Blaze Tablet
Revision: 20edb4
[...]
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/include/asm/setup.h |1 +
arch/arm/kernel/setup.c |9 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index c50f056..621df40 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -52,5 +52,6 @@ extern struct meminfo meminfo;
extern int arm_add_memory(phys_addr_t start, phys_addr_t size);
extern void early_print(const char *str, ...);
extern void dump_machine_table(void);
+extern void set_soc_model_name(char *name);
#endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..bb3805f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -134,6 +134,7 @@ char elf_platform[ELF_PLATFORM_SIZE];
EXPORT_SYMBOL(elf_platform);
static const char *cpu_name;
+static const char *soc_name;
static const char *machine_name;
static char __initdata cmd_line[COMMAND_LINE_SIZE];
struct machine_desc *machine_desc __initdata;
@@ -493,6 +494,11 @@ static void __init setup_processor(void)
cpu_init();
}
+void set_soc_model_name(char *name)
+{
+ soc_name = name;
+}
+
void __init dump_machine_table(void)
{
struct machine_desc *p;
@@ -902,6 +908,9 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, CPU revision\t: %d\n\n, cpuid 15);
}
+ if (soc_name)
+ seq_printf(m, SoC name\t: %s\n\n, soc_name);
+
seq_printf(m, Hardware\t: %s\n, machine_name);
seq_printf(m, Revision\t: %04x\n, system_rev);
seq_printf(m, Serial\t\t: %08x%08x\n,
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On 16:23 Fri 09 Nov , Stephen Warren wrote: On 11/09/2012 09:28 AM, Grant Likely wrote: On Tue, Nov 6, 2012 at 10:37 PM, Stephen Warren swar...@wwwdotorg.org wrote: ... I do rather suspect this use-case is quite common. NVIDIA certainly has a bunch of development boards with pluggable PMIC/audio/WiFi/display/..., and I believe there's some ability to re-use the pluggable components with a variety of base-boards. Given people within NVIDIA started talking about this recently, I asked them to enumerate all the boards we have that support pluggable components, and how common it is that some boards support being plugged into different main boards. I don't know when that enumeration will complete (or even start) but hopefully I can provide some feedback on how common the use-case is for us once it's done. From your perspective, is it important to use the exact same .dtb overlays for those add-on boards, or is it okay to have a separate build of the overlay for each base tree? I certainly think it'd be extremely beneficial to use the exact same child board .dtb with arbitrary base boards. Consider something like the Arduino shield connector format, which I /believe/ has been re-used across a wide variety of Arduino boards and other compatible or imitation boards. Now consider a vendor of an Arduino shield. The shield vendor probably wants to publish a single .dtb file that works for users irrespective of which board they're using it with. (Well, I'm not sure that Arduino can run Linux; perhaps that's why you picked BeagleBone capes for your document!) I suppose it would be acceptable for the shield vendor to ship the .dts file rather than the .dtb, and hence need to build the shield .dtb for a specific base board. However, I think the process for an end-user needs to be as simple as drop this .dts/.dtb file into some standard directory, and I imagine it'll be much easier for distros/... to make that process work if they're dealing with a .dtb that they can just blast into the kernel's firmware loader interface, rather than having to also locate the base-board .dts/.dtb file, and run dtc and/or other tools on both .dts files together. I've exactly the same issue on Calao or the new atmel boards We have lego boards with different cpu-modues running on differetn mother boards with diferrentdaugther boards on atmel we are lucky enough we can identity via 1-wire all of them but on Calao no On Somfy platform we can detect hardware version and need different pinctrl So personally I'll prefer to be able to request dtb from the kernel or push them from the userspace as it will depends where you will detect the hardware present The main concern will which part of the kenel will now handle hw detection? Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On 21:12 Sun 28 Oct , Linus Walleij wrote: On Wed, Oct 24, 2012 at 7:28 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: drivers/spi/spi-pl022.c Default/sleep transitions could be moved into bus code. No that's not a good idea as long as we have both the platform bus and the AMBA bus doing essentially the same thing. We will then be having two copies of the same code in two different busses running out of sync. There may be other busses too. But I could prepare static helpers in linux/pinctrl/consumer.h that any bus could use. Or any driver. Probably any driver, because of this: As noted the bus cannot really execute the pinctrl calls to e.g. put a drivers pins into sleep. Since if e.g. the bus is walking the suspend() ladder, shall it put the pins into sleep *before* or *after* calling the suspend() hook in the driver? The answer is that it does not know. Because drivers have different needs. Depending on how the hardware and system is done. I already tried to make this point: pinctrl_set_state(state_sleep); clk_disable(); power_off_voltage_domain(); May for some drivers have to be: clk_disable(); power_off_voltage_domain(); pinctrl_set_state(state_sleep); (etc) I'm not making this up, it is a very real phenomenon on the Ux500 and I don't think we are unique. I agree with Linus you can not handle pinctrl as bus levell as each driver need different requirement before enabling the pin as example you may need to clock the ip before muxing the pin and invertly on some IP the pinctrl is optionnal, on other mandatory you can not expect every driver to have the same need and requirement yes we will have a few code duplication but today it's few lines and those few lines will be place at different init stage on the drivers ditto for remove or sleep/idle Moving this handling to bus code or anywhere else invariably implies that resource acquisition/release order does not matter, and my point is that it does. 100% agreed Best Regards, J. drivers/i2c/busses/i2c-nomadik.c Don't see pinctrl in linux-next. This code is here: http://marc.info/?l=linux-i2cm=134986995731695w=2 Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: add PROC_DEVICETREE support in Kconfig
On 18:38 Fri 06 Jul , jgq...@gmail.com wrote: From: Xiao Jiang jgq...@gmail.com Since more and more arm chips support device tree, it'd be better add PROC_DEVICETREE in arch/arm/Kconfig to avoid duplicate code. Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Best Regards, J. Signed-off-by: Xiao Jiang jgq...@gmail.com --- arch/arm/Kconfig |1 + arch/arm/configs/at91_dt_defconfig |1 - arch/arm/configs/tegra_defconfig |1 - arch/arm/plat-omap/Kconfig |1 - 4 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a91009c..f68896e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1864,6 +1864,7 @@ config USE_OF select OF select OF_EARLY_FLATTREE select IRQ_DOMAIN + select PROC_DEVICETREE if PROC_FS help Include support for flattened device tree machine descriptions. diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 67bc571..b856cb6 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -64,7 +64,6 @@ CONFIG_MTD_NAND=y CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_GLUEBI=y -CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 1198dd6..43e7b65 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -72,7 +72,6 @@ CONFIG_IPV6_TUNNEL=y CONFIG_IPV6_MULTIPLE_TABLES=y # CONFIG_WIRELESS is not set # CONFIG_FIRMWARE_IN_KERNEL is not set -CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_AD525X_DPOT=y CONFIG_AD525X_DPOT_I2C=y diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index ad95c7a..4e2cb17 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -27,7 +27,6 @@ config ARCH_OMAP2PLUS select GENERIC_IRQ_CHIP select OMAP_DM_TIMER select USE_OF - select PROC_DEVICETREE if PROC_FS help Systems based on OMAP2, OMAP3 or OMAP4 -- 1.7.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/13] ARM: OMAP5: id: Add cpu id for ES versions
On 12:56 Thu 03 May , R Sricharan wrote:
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
arch/arm/mach-omap2/id.c | 47
+
arch/arm/plat-omap/include/plat/cpu.h | 23 ++-
3 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index a406fd0..9daac6f 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -246,6 +246,10 @@
/* TI81XX CONTROL_DEVCONF register offsets */
#define TI81XX_CONTROL_DEVICE_ID (TI81XX_CONTROL_DEVCONF + 0x000)
+/* OMAP54XX CONTROL STATUS register */
+#define OMAP5XXX_CONTROL_STATUS0x134
+#define OMAP5_DEVICETYPE_MASK (0x7 6)
+
/*
* REVISIT: This list of registers is not comprehensive - there are more
* that should be added.
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 0e79b7b..d2ec323 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -50,6 +50,11 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ } else if (cpu_is_omap54xx()) {
+ val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
+ val = OMAP5_DEVICETYPE_MASK;
+ val = 6;
+ goto out;
} else {
pr_err(Cannot detect omap type!\n);
goto out;
@@ -500,6 +505,48 @@ void __init omap4xxx_check_revision(void)
((omap_rev() 12) 0xf), ((omap_rev() 8) 0xf));
}
+void __init omap5xxx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb942:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5430_REV_ES1_0;
why do you duplicate this
+ break;
+ case 1:
+ omap_revision = OMAP5430_REV_ES2_0;
+ break;
do this
case 0:
+ default:
+ omap_revision = OMAP5430_REV_ES1_0;
+ }
+ break;
+
+ case 0xb998:
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP5432_REV_ES1_0;
+ break;
+ default:
ditto here
+ omap_revision = OMAP5432_REV_ES1_0;
+ }
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 08:03 Fri 04 May , Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 22:08]:
In my mind in the driver we do not have to care how to list
register/unregister the group. We just need to be able to do this
pinctrl_register_group(...)
or
pinctrl_unregistewr_group(...)
On at91 we have this type of controller
Ah I see. Yeah makes sense. Also I think we should let the pinctrl
core eventually manage the pins more too. Right now the pins are
a static array in the driver, which makes things unnecessarily
complex for the DT case. It would be nice to also have something like
pinctrl_register/unregister_pin instead of requiring them all
be registered while registering with the framework initially.
But all that can be improved later on once we get the binding down..
agreed at 100%
one pin can have multiple function and each function can be on different pin
and we need to program and represent each of them one by one
And each pin have different parameter
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
Hmm I assume the 12 above the gpio number?
no pin number in the bank because it could not be gpio
evenif on at91 and nearly on the controller I known it is the case
and use macro as basicaly we are just this
and this can be applied to tegra too as you will just refer the pin in this
hw
pin block
I was thinking of adding gpio eventually as a separate attribute with
something like the following. Here cam_d10 pin is used as gpio109:
cam_d10.gpio_109 {
pinctrl-simple,cells = 0xfa 0x104;/* OMAP_PIN_INPUT |
OMAP_MUX_MODE4 */
gpio = gpio4 13 0; /* gpio109 */
};
The reasoning for this is that as we may not care about the gpio number
for all pins, it should be optional. Would that work for you?
yes
but I was thinking to put it as a param but why not
my idea was this
pinctrl@f200 {
#address-cells = 1;
#size-cells = 0;
compatible = atmel,at91rm9200-pinctrl;
atmel,mux-mask =
/*A B */
0x 0xffc003ff /* pioA */
0x 0x800f8f00 /* pioB */
0x 0x0e00 /* pioC */
0x 0xff0c1381 /* pioD */
0x 0x8181 /* pioE */
;
pioA: gpio@f200 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf200 0x100;
interrupts = 2 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioB: gpio@f400 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf400 0x100;
interrupts = 3 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioC: gpio@f600 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf600 0x100;
interrupts = 4 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioD: gpio@f800 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf800 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fa00 {
compatible = atmel,at91rm9200-gpio;
reg = 0xfa00 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = pioB 12 0 0
pioB 13 0 2 ;
/* with macro */
pins = pioB 12 MUX_A NO_PULL_UP
pioB 13 MUX_A PULL_UP ;
};
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = pioB 19 MUX_A PULL_UP /* rxd */
pioB 18 MUX_A NO_PULL_UP ; /* txd */
};
uart0_rts_cts {
groups = uart0_rxd_txd ;
pins = pioB 17 MUX_B NO_PULL_UP /* rts */
pioB 15 MUX_B NO_PULL_UP ; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = uart0_rts_cts ;
gpios = pioC 1 0;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Best Regards,
J
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 09:34 Fri 04 May , Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120504 08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
Hmm I assume the 12 above the gpio number?
no pin number in the bank because it could not be gpio
Yes OK, but pin number 12 in the gpio bank, not in the mux register.
Got it.
pioD: gpio@f800 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf800 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fa00 {
compatible = atmel,at91rm9200-gpio;
reg = 0xfa00 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = pioB 12 0 0
pioB 13 0 2 ;
/* with macro */
pins = pioB 12 MUX_A NO_PULL_UP
pioB 13 MUX_A PULL_UP ;
};
I could change to use this too no problem. The only concern I have is
that is pioB 12 immutable for all gpio controllers?
Grepping the *.dts* files, at least exynos is using the following
for gpios:
gpios = gpx2 0 0 0 2;
If we can conclude that phandle to the gpio controller instance and
the register offset is always enough here, then I'm OK changing to
that format. It would actually save some parsing in most cases.
I would said yes but we could use the same notion to create pin-bank
the idea is to refer to the bank and then the pin inside
after if a driver need more argumement as on exynos they will have to
implement their own xlate
as we did on at91 for the irq xlate
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = pioB 19 MUX_A PULL_UP /* rxd */
pioB 18 MUX_A NO_PULL_UP ; /* txd */
};
uart0_rts_cts {
groups = uart0_rxd_txd ;
pins = pioB 17 MUX_B NO_PULL_UP /* rts */
pioB 15 MUX_B NO_PULL_UP ; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = uart0_rts_cts ;
gpios = pioC 1 0;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Yeah sounds doable to me, but can probably be added later?
for the sub-group stuff yes agreed
Regarding grouping, basically for most cases it makes sense to have
three states: default, active, idle instead of just active and idle.
The reason is that for most cases the default pins only need to be
set once for each devices. Only few pins need to toggle between
active and idle states.
yeah agreed
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 12:55 Fri 04 May , Stephen Warren wrote:
On 05/04/2012 10:34 AM, Tony Lindgren wrote:
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120504 08:58]:
On 08:03 Fri 04 May , Tony Lindgren wrote:
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
Hmm I assume the 12 above the gpio number?
no pin number in the bank because it could not be gpio
Yes OK, but pin number 12 in the gpio bank, not in the mux register.
Got it.
I'd prefer to avoid any references to GPIOs here; not all muxable pins
are GPIOs and not all GPIOs are muxable pins. Lets keep the two concepts
independent.
my idea was to have a phandle pinctrl specific to represent the bank
and use it in the same way as done on gpio
pioD: gpio@f800 {
compatible = atmel,at91rm9200-gpio;
reg = 0xf800 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fa00 {
compatible = atmel,at91rm9200-gpio;
reg = 0xfa00 0x100;
interrupts = 5 4;
#gpio-cells = 2;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = pioB 12 0 0
pioB 13 0 2 ;
/* with macro */
pins = pioB 12 MUX_A NO_PULL_UP
pioB 13 MUX_A PULL_UP ;
};
I could change to use this too no problem. The only concern I have is
that is pioB 12 immutable for all gpio controllers?
You mean is the number of cells used to specify a GPIO the same
everywhere? No. It's defined by #gpio-cells in the GPIO controller node.
But again, the GPIO binding shouldn't be related to the pinctrl binding
directly.
Grepping the *.dts* files, at least exynos is using the following
for gpios:
gpios = gpx2 0 0 0 2;
If we can conclude that phandle to the gpio controller instance and
the register offset is always enough here, then I'm OK changing to
that format. It would actually save some parsing in most cases.
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = pioB 19 MUX_A PULL_UP /* rxd */
pioB 18 MUX_A NO_PULL_UP ; /* txd */
};
I don't really see how that DT format represents pins, functions, and
nodes directly, and separately from which of those a board chooses to
use. I think this binding and the one Tony originally proposed are
eseentially semantically identical.
Going back to my idea of separating SoC and board configurations, if we
did that, I'd expect to see something more like:
soc.dtsi or board.dts:
This is the data that the pin controller driver needs to export to
pinctrl core. This can be completely enumerated in the soc.dtsi, or
perhaps for uncommonly used pins/groups/functions, only included in the
board.dts that actually uses it to cut down on soc.dtsi's size:
This data is not needed for SoCs whose pinctrl drivers include it in
their driver file instead of DT.
I agree on at91 I propose exactly this but get the following comment tat we
are going to have too much node.
so the idea I propoose with the pins array is to avoid this issue
my first bindings on at91
functions {
};
1) we describe one functin per pin
functions {
rxd_pb12 {
atmel,pin-id = pioB 12;
atmel,mux = 0;
};
txd_pb13 {
atmel,pin-id = piaB 13;
atmel,pull = 2;
atmel,mux = 0;
};
txd0_pb19 {
atmel,pin-id = pioB 19;
atmel,pull = 2;
atmel,mux = 0;
};
rxd0_pb18 {
atmel,pin-id = pioB 18;
atmel,mux = 0;
};
rts0_pb17 {
atmel,pin-id = pioB 17;
atmel,mux = 1;
};
cts0_pb15 {
atmel,pin-id = pioB 15;
atmel,mux = 1;
};
};
groups {
dbgu {
pinctrl,functions =
rxd_pb12 txd_pb13 ;
};
uart0_rxd_txd {
pinctrl,functions =
rxd0_pb18 txd0_pb19 ;
};
uart0_rts_cts {
pinctrl,functions =
rxd0_pb18 txd0_pb19
rts0_pb17 cts0_pb15 ;
};
};
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
Hi,
I really like it
I was working on something simillar
but can we split the group management so we can use it on other
bindings
Best Regards,
J.
On 10:24 Wed 02 May , Tony Lindgren wrote:
Add simple pinctrl driver using device tree data.
Currently this driver only works on omap2+ series of
processors, where there is either an 8 or 16-bit padconf
register for each pin. Support for other similar pinmux
controllers could be added.
Note that this patch does not yet support pinconf_ops
or GPIO. Further.
Signed-off-by: Tony Lindgren t...@atomide.com
---
Here's this one finally updated to use the common pinctrl bindings.
That sure cleaned up a bunch of the nasty things in this driver :)
Nice job Stephen!
---
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
new file mode 100644
index 000..7b32263
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-simple.txt
@@ -0,0 +1,125 @@
+Generic simple device tree based pinctrl driver
+
+Required properties:
+- compatible : one of:
+ - pinctrl-simple
+ - ti,omap2420-padconf
+ - ti,omap2430-padconf
+ - ti,omap3-padconf
+ - ti,omap4-padconf
+- reg : offset and length of the register set for the mux registers
+- #pinctrl-cells : width of the pinctrl array, currently only 2 is supported
+- pinctrl-simple,register-width : pinmux register access width
+- pinctrl-simple,function-mask : mask of allowed pinmux function bits
+- pinctrl-simple,function-off : function off mode for disabled state
+- pinctrl-simple,pinconf-mask : mask of allowed pinconf bits
+
+This driver uses the common pinctrl bindings as specified in
+pinctrl-bindings.txt document in this directory. The common bindings are used
+to specify the client device states using pinctrl-0 and pinctrl-names
entries.
+
+This driver supports parsing one or more pinctrl functions as the subnodes of
+the pinctrl driver entry. One or more registers can be specified for each
+function, see uart2 and uart3 examples below. If you are concerned about boot
+time, parsing multiple registers in a single function is slightly faster.
+
+For setting all static board specific pins, see the pinmux_board_pins example
+below. If you are concerned about the boot time, set up the static pins in
+the bootloader, and only set up selected pins as device tree entries.
+
+This driver assumes currently that there is one register for each pin. If you
+have some pins with more complicated configuration, you can set up a separate
+hardware specific driver for those pins.
+
+Example:
+
+/* SoC common file, such as omap4.dtsi */
+omap4_pmx_core: pinmux@4a100040 {
+ compatible = ti,omap4-padconf;
+ reg = 0x4a100040 0x0196;
+ #address-cells = 1;
+ #size-cells = 0;
+ #pinctrl-cells = 2;
+ pinctrl-simple,register-width = 16;
+ pinctrl-simple,function-mask = 0x7;
+ pinctrl-simple,function-off = 0x;
+ pinctrl-simple,pinconf-mask = 0xfff8;
+};
+
+omap4_pmx_wkup: pinmux@4a31e040 {
+ compatible = ti,omap4-padconf;
+ reg = 0x4a31e040 0x0038;
+ #address-cells = 1;
+ #size-cells = 0;
+ #pinctrl-cells = 2;
+ pinctrl-simple,register-width = 16;
+ pinctrl-simple,function-mask = 0x7;
+ pinctrl-simple,function-off = 0x;
+ pinctrl-simple,pinconf-mask = 0xfff8;
+};
+
+
+/* board specific .dts file, such as omap4-sdp.dts */
+omap4_pmx_core {
+
+ /*
+ * map all board specific static pins enabled by the pinctrl driver
+ * itself during the boot (or just set them up in the bootloader)
+ */
+ pinctrl-names = default;
+ pinctrl-0 = board_pins;
+
+ board_pins: pinmux_board_pins {
+ board_static_pins {
+ pinctrl-simple,cells =
+ 0x6c 0xf/* CSI21_DX3 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x6e 0xf/* CSI21_DY3 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x70 0xf/* CSI21_DX4 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ 0x72 0xf/* CSI21_DY4 OMAP_PIN_OUTPUT |
OMAP_MUX_MODE7 */
+ ;
+ };
+ };
+
+
+ /* map all uart2 pins as a single function */
+ uart2_pins: pinmux_uart2_pins {
+ uart2_pins {
+ pinctrl-simple,cells =
+ 0xd8 0x118 /* UART2_CTS
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0 */
+ 0xda 0 /* UART2_RTS OMAP_PIN_OUTPUT |
OMAP_MUX_MODE0 */
+ 0xdc 0x118 /* UART2_RX
OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0 */
+ 0xde 0 /* UART2_TX OMAP_PIN_OUTPUT |
OMAP_MUX_MODE0 */
+ ;
+
Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
On 16:34 Thu 03 May , Stephen Warren wrote:
On 05/03/2012 09:27 AM, Tony Lindgren wrote:
Hi,
* Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com [120503 00:16]:
I really like it
I was working on something simillar
but can we split the group management so we can use it on other
bindings
Hmm I'm not sure I follow on the group management splitting, can you specify
what you have in mind here?
If you mean moving more things into pinctrl fwk, then yeah I'd assume that
will happen eventually and drivers like this will end up becoming more
minimal.
Jean-Christophe, forgive me if I'm putting words in your mouth, but I
assume the following is what you mean:
There are two pieces of data required by the pinctrl subsystem:
a) The set of pins, functions, and groups that exist.
b) The specific function to select for each pin/group on a given board.
Item (a) can be represented in the pinctrl driver (e.g. as in the Tegra
driver), or can be represented in device tree in order to avoid large
tables in the driver.
Item (b) has to be represented in device tree, since the whole point is
that it's board-specific.
For all DT bindings I've seen that choose to represent (a) in the DT
rather than in the driver, the DT represents (b) directly, and (a) is
implicitly extracted/created based on (a).
When I was first thinking about DT bindings for pinctrl, I had hoped
that even if (a) was represented in DT, the DT nodes/properties for (a)
and (b) would be entirely separate, so that the binding for (b) could be
completely common across all SoCs, even though the binding for (a) would
perhaps be different across SoCs (if it existed at all).
So, perhaps Jean-Christophe is talking about splitting up (a) and (b) in
device tree?
Or perhaps Jean-Christophe only refers to the code that creates the
group and function definitions from (b), and not the actual DT binding
itself?
yes you are right Stephen
I was thinking of both but the second could be a first step
today we tend all to represent the group of pin in DT
for TI, IM, MXC, at91, ST and others
the way to represend the groups are exactly the same
a group is a node with a set on pin
uart {
pincfg..
}
and the group is uart
so we do need to have a common way to handle it in c
the code propose by Tony is really what I'm working on to acheive this
In my mind in the driver we do not have to care how to list
register/unregister the group. We just need to be able to do this
pinctrl_register_group(...)
or
pinctrl_unregistewr_group(...)
On at91 we have this type of controller
one pin can have multiple function and each function can be on different pin
and we need to program and represent each of them one by one
And each pin have different parameter
so I was thinking to do like on gpio
uart {
pin = pioA 12 {pararms}
}
and use macro as basicaly we are just this
and this can be applied to tegra too as you will just refer the pin in this hw
pin block
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
On 07:06 Thu 12 Apr , Mohammed, Afzal wrote:
+ omap ml
Hi Jean, Andrew, Nicolas,
On Wed, Apr 11, 2012 at 21:31:13, Jean-Christophe PLAGNIOL-VILLARD wrote:
+ ahb {
+ apb {
+ dbgu: serial@f200 {
+ status = okay;
+ };
+
+ usart0: serial@fffb {
+ status = okay;
+ };
+
+ usart1: serial@fffb4000 {
+ status = okay;
+ };
+
+ macb0: ethernet@fffc4000 {
+ phy-mode = rmii;
+ status = okay;
+ };
+
+ usb1: gadget@fffa4000 {
+ atmel,vbus-gpio = pioC 5 0;
+ status = okay;
+ };
+ };
+
+ nand0: nand@4000 {
+ nand-bus-width = 8;
+ nand-ecc-mode = soft;
+ nand-on-flash-bbt;
+ status = okay;
I have a few queries about handling static memory controller (SMC) of ATMEL
1. How is SMC configured when DT is used ?
2. With d6a0166 atmel/nand: add DT support, ek_add_device_nand() is no more
present (which was earlier configuring SMC), so is SMC configuration handled
by Kernel on DT boot or is it done by bootloader when DT ?
3. How ek_add_device_dm9000() is going to be achieved with DT ?
4. Is there any plan to create a driver out of SMC code use DT with it ?
Reason for bringing these queries is that TI OMAP chips have GPMC [1], SMC in
ATMEL
seems somewhat similar and currently GPMC is configured in platform code,
we are creating a driver out of that code [2]. There are different views on
where
GPMC driver should go, mfd, misc folders etc, but could not yet get concrete
suggestions even with a loud cry.
put me in ccc I'll take a look
If ATMEL is also going driver way, then probably our voice together may be
heard and hopefully it will expedite the matter.
I'm going to add it too my idea was to create something similiar as the
pintrl
you register the ddifferent bank supported buy the SoC and then the driver
request the bank for the dev_name
at soc level you will set the default timings and then the drvier may
manipulate them
I already update the API of sam9_smc to abstract the access to the register.
I expect the code for the request to be generic but handling of the timing IP
specific
Evenif the GPMC is smiliar as the SMC I do not expect a generic API to manage
it easly (for the timings).
Best Regrds,
J
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
On 12:14 Thu 12 Apr , Mohammed, Afzal wrote: Hi Jean, On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote: If ATMEL is also going driver way, then probably our voice together may be heard and hopefully it will expedite the matter. I'm going to add it too my idea was to create something similiar as the pintrl you register the ddifferent bank supported buy the SoC and then the driver request the bank for the dev_name at soc level you will set the default timings and then the drvier may manipulate them I already update the API of sam9_smc to abstract the access to the register. Is SMC code being converted to driver ? no I'm busy on pinctrl I just cereate an abstracted API Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/17] ARM: mark const init data with __initconst instead of __initdata
On 23:12 Thu 29 Mar , Uwe Kleine-König wrote: As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Cc: Andrew Victor li...@maxim.org.za Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Russell King li...@arm.linux.org.uk Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Kukjin Kim kgene@samsung.com Cc: Sascha Hauer ker...@pengutronix.de Cc: Shawn Guo shawn@linaro.org Cc: Lennert Buytenhek ker...@wantstofly.org Cc: Nicolas Pitre n...@fluxnic.net Cc: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: David Brown dav...@codeaurora.org Cc: Daniel Walker dwal...@fifo99.com Cc: Bryan Huntsman bry...@codeaurora.org Cc: Tony Lindgren t...@atomide.com Cc: Barry Song baohua.s...@csr.com Cc: Andrew Lunn and...@lunn.ch Cc: Lucas De Marchi lucas.demar...@profusion.mobi Cc: linux-arm-ker...@lists.infradead.org Cc: davinci-linux-open-sou...@linux.davincidsp.com Cc: linux-samsung-...@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: linux-omap@vger.kernel.org --- arch/arm/mach-at91/board-dt.c |2 +- arch/arm/mach-at91/clock.c|2 +- for at91 Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On 16:28 Tue 22 Nov , Stephen Warren wrote:
Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
* Linus Walleij linus.wall...@linaro.org [22 03:30]:
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
thomas.abra...@linaro.org wrote:
On 17 November 2011 19:27, Linus Walleij linus.wall...@linaro.org
wrote:
Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.
Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.
If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.
OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.
Yes the driver nodes should describe in DT which pins to use:
serial@1234 {
compatible = 8250;
reg = 0x1234 0x40;
reg-shift = 2;
interrupts = 10 ;
pins = uart1_rx, uart1_tx;
};
Sorry to jump in late here, but I wasn't aware of this thread.
I don't necessarily agree with that. Describing the HW doesn't necessarily
mean that each device needs to describe what pinmux pins it uses; one
could quite easily have the pinmux describe what settings the various
pins should have and which drivers will use those pins. That would map
very well to the pinctrl subsystem's mapping table, and at least Tegra's
existing pinmux tables, which are both just a big array of settings which
end up getting provided to drivers.
I'll try and track down the rest of this thread and catch up though...
I agreee here
as example on at91 I try to found a good way to let the macb driver to ask the
pin configuration
so in my mind i do not need put all pins in each board but in the dtsi and
then in the drivers just said
pins = mii;
or
pins = rmii;
or if I want to use the alternative config
pins = mii_alt;
or
pins = rmii_alt;
and then in the dtsi I describe the pin used for those configs
which is soc specifific not board
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v4] Consolidate SRAM support
From: Russell King - ARM Linux li...@arm.linux.org.uk
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Let's unify this before we have additional SoCs re-implementing this
obviously common functionality themselves.
For this use the generic allocator and the newly introduce
gen_pool_add_virt and gen_pool_virt_to_phys
Uio_pruss should probably take the SRAM pool pointer via
platform data so that it doesn't have to include Davinci specific
includes.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sascha Hauer ker...@pengutronix.de
---
v4:
update against linus tree and genalloc gen_pool_add_virt and
gen_pool_virt_to_phys
Best Regards,
J.
arch/arm/Kconfig |2 +
arch/arm/mach-davinci/da850.c |2 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/common.h|2 +-
arch/arm/mach-davinci/include/mach/sram.h | 13 +
arch/arm/mach-davinci/pm.c | 21 +++
arch/arm/mach-davinci/sram.c | 57 +--
arch/arm/plat-mxc/include/mach/iram.h | 28 --
.../plat-mxc/{include/mach/iram.h = iram_alloc.c} | 40 --
arch/arm/plat-omap/include/plat/sram.h | 19 +--
arch/arm/plat-omap/sram.c | 38 +
drivers/uio/uio_pruss.c| 10 +++-
sound/soc/davinci/davinci-pcm.c| 11 +++--
16 files changed, 122 insertions(+), 129 deletions(-)
copy arch/arm/plat-mxc/{include/mach/iram.h = iram_alloc.c} (56%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f4b7dfa..5ec5e5f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -848,6 +848,7 @@ config ARCH_DAVINCI
bool TI DaVinci
select GENERIC_CLOCKEVENTS
select ARCH_REQUIRE_GPIOLIB
+ select GENERIC_ALLOCATOR
select ZONE_DMA
select HAVE_IDE
select CLKDEV_LOOKUP
@@ -862,6 +863,7 @@ config ARCH_OMAP
select HAVE_CLK
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
+ select GENERIC_ALLOCATOR
select GENERIC_CLOCKEVENTS
select HAVE_SCHED_CLOCK
select ARCH_HAS_HOLES_MEMORYMODEL
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index b95b919..09f6c12 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 = {
.gpio_irq = IRQ_DA8XX_GPIO0,
.serial_dev = da8xx_serial_device,
.emac_pdata = da8xx_emac_pdata,
- .sram_dma = DA8XX_ARM_RAM_BASE,
+ .sram_phys = DA8XX_ARM_RAM_BASE,
.sram_len = SZ_8K,
.reset_device = da8xx_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a3a94e9..9bda687 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
.gpio_num = 104,
.gpio_irq = IRQ_DM355_GPIOBNK0,
.serial_dev = dm355_serial_device,
- .sram_dma = 0x0001,
+ .sram_phys = 0x0001,
.sram_len = SZ_32K,
.reset_device = davinci_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 = {
.gpio_unbanked = 8,/* really 16 ... skip muxed GPIOs */
.serial_dev = dm365_serial_device,
.emac_pdata = dm365_emac_pdata,
- .sram_dma = 0x0001,
+ .sram_phys = 0x0001,
.sram_len = SZ_32K,
.reset_device = davinci_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 4c82c27..3949ed7 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -764,7 +764,7 @@ static struct davinci_soc_info davinci_soc_info_dm644x = {
.gpio_irq = IRQ_GPIOBNK0,
.serial_dev = dm644x_serial_device,
.emac_pdata
Re: [RFC PATCH v3] Consolidate SRAM support
On 18:45 Thu 12 May , Russell King - ARM Linux wrote: On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. Let's unify this before we have additional SoCs re-implementing this obviously common functionality themselves. Unfortunately, we end up with code growth through doing this, but that will become a win when we have another SoC using this (which I know there's at least one in the pipeline). One of the considerations here is that we can easily convert sram-pool.c to hook into device tree stuff, which can tell the sram allocator: - physical address of sram - size of sram - allocation granularity and then we just need to ensure that it is appropriately mapped. This uses the physical address, and unlike Davinci's dma address usage, it always wants to have the physical address, and will always return the corresponding physical address when passed that pointer. OMAP could probably do with some more work to make the omapfb and other allocations use the sram allocator, rather than hooking in before the sram allocator is initialized - and then further cleanups so that we have an initialization function which just does sram_create(phys, size) virt = map sram(phys, size) create sram pool(virt, phys, size, min_alloc_order) Another question is whether we should allow multiple SRAM pools or not - this code does allow multiple pools, but so far we only have one pool per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate it if they want to partition the SRAM, or have peripheral-local SRAMs. Lastly, uio_pruss should probably take the SRAM pool pointer via platform data so that it doesn't have to include Davinci specific includes. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- This version fixes the davinci pm free, and adds updates for the davinci pcm driver. As I don't know what's happening with Jean's patch tweaking the genpool allocator, I've kept my version. This still suffers from the only one region per pvpool problem which I believe Jean's patch doesn't suffer. yes excatly and on at91sam9263 I need this :( Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] Consolidate SRAM support
Hi,
I do post a patch to add the support to specify a virt and phys
address to the generic allocator so the pv-pool.c is not needed
we can just use the generic fucntion
I'll post a v3 updated again it
Best Regards,
J.
--- /dev/null +++ b/arch/arm/common/pv-pool.c
@@ -0,0 +1,69 @@
+/*
+ * Unified Phys/Virt allocator, based on mach-davinci/sram.c, which was
+ * Copyright (C) 2009 David Brownell.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include linux/dma-mapping.h
+#include linux/genalloc.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+
+#include asm/pv-pool.h
+
+struct pv_pool {
+ struct gen_pool *genpool;
+ void *cpu_base;
+ phys_addr_t phys_base;
+};
+
+void *pv_pool_alloc(struct pv_pool *pool, size_t len, phys_addr_t *phys)
+{
+ void *addr = (void *)gen_pool_alloc(pool-genpool, len);
+
+ if (phys)
+ *phys = addr ? (pool-phys_base + (addr - pool-cpu_base)) :
+ (phys_addr_t)-1ULL;
+
+ return addr;
+}
+EXPORT_SYMBOL_GPL(pv_pool_alloc);
+
+void pv_pool_free(struct pv_pool *pool, void *addr, size_t len)
+{
+ gen_pool_free(pool-genpool, (unsigned long)addr, len);
+}
+EXPORT_SYMBOL_GPL(pv_pool_free);
+
+struct pv_pool *pv_pool_create(void *addr, phys_addr_t phys, size_t len,
+ int min_alloc_order)
+{
+ struct pv_pool *pool = kzalloc(sizeof(struct pv_pool), GFP_KERNEL);
+
+ if (pool) {
+ pool-cpu_base = addr;
+ pool-phys_base = phys;
+ pool-genpool = gen_pool_create(min_alloc_order, -1);
+ if (!pool-genpool) {
+ kfree(pool);
+ pool = NULL;
+ } else {
+ WARN_ON(gen_pool_add(pool-genpool, (unsigned long)addr,
+ len, -1) 0);
+ }
+ }
+
+ return pool;
+}
+EXPORT_SYMBOL_GPL(pv_pool_create);
+
+void pv_pool_destroy(struct pv_pool *pool)
+{
+ gen_pool_destroy(pool-genpool);
+ kfree(pool);
+}
+EXPORT_SYMBOL_GPL(pv_pool_destroy);
diff --git a/arch/arm/include/asm/pv-pool.h b/arch/arm/include/asm/pv-pool.h
new file mode 100644
index 000..b7ae871
--- /dev/null
+++ b/arch/arm/include/asm/pv-pool.h
@@ -0,0 +1,20 @@
+#ifndef __ASMARM_PV_POOL_H
+#define __ASMARM_PV_POOL_H
+
+#include asm/fncpy.h
+
+struct pv_pool;
+
+void *pv_pool_alloc(struct pv_pool *, size_t, phys_addr_t *);
+void pv_pool_free(struct pv_pool *, void *, size_t);
+struct pv_pool *pv_pool_create(void *, phys_addr_t, size_t, int);
+void pv_pool_destroy(struct pv_pool *);
+
+/* Macro to copy a function into SRAM, using the fncpy API */
+#define pv_pool_fncpy(pool, funcp, size) ({ \
+ size_t _sz = size; \
+ void *_sram = pv_pool_alloc(pool, _sz, NULL); \
+ (_sram ? fncpy(_sram, (funcp), _sz) : NULL); \
+})
+
+#endif
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 68fe4c2..5eca128 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1099,7 +1099,7 @@ static struct davinci_soc_info davinci_soc_info_da850 =
{
.gpio_irq = IRQ_DA8XX_GPIO0,
.serial_dev = da8xx_serial_device,
.emac_pdata = da8xx_emac_pdata,
- .sram_dma = DA8XX_ARM_RAM_BASE,
+ .sram_phys = DA8XX_ARM_RAM_BASE,
.sram_len = SZ_8K,
.reset_device = da8xx_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 76364d1..3df8730 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -850,7 +850,7 @@ static struct davinci_soc_info davinci_soc_info_dm355 = {
.gpio_num = 104,
.gpio_irq = IRQ_DM355_GPIOBNK0,
.serial_dev = dm355_serial_device,
- .sram_dma = 0x0001,
+ .sram_phys = 0x0001,
.sram_len = SZ_32K,
.reset_device = davinci_wdt_device,
};
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 4604e72..d306034 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1082,7 +1082,7 @@ static struct davinci_soc_info davinci_soc_info_dm365 =
{
.gpio_unbanked = 8,/* really 16 ... skip muxed GPIOs */
.serial_dev = dm365_serial_device,
.emac_pdata = dm365_emac_pdata,
- .sram_dma = 0x0001,
+ .sram_phys = 0x0001,
Re: [RFC PATCH v2] Consolidate SRAM support
On 17:18 Tue 19 Apr , Russell King - ARM Linux wrote:
On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
Hi,
I do post a patch to add the support to specify a virt and phys
address to the generic allocator so the pv-pool.c is not needed
we can just use the generic fucntion
You've talked about this before in the thread, but the patch never appeared.
I forget to re-send it sorry
it's the mm tree
patch attached
Best Regards,
J.
From 05f5a21ca6423b3051d442eaad3ba34ac131ef98 Mon Sep 17 00:00:00 2001
From: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Date: Thu, 7 Apr 2011 01:23:45 +0800
Subject: [PATCH] genalloc: add support to specify the physical address
so we specify the virtual address as base of the pool chunk and then
get the physical address for hardware IP
as example on at91 we will use on spi, uart or macb
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
include/linux/genalloc.h | 20 +++-
lib/genalloc.c | 39 ---
2 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index b1c70f1..b44625b 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -26,13 +26,31 @@ struct gen_pool {
struct gen_pool_chunk {
spinlock_t lock;
struct list_head next_chunk; /* next chunk in pool */
+ unsigned long phys_addr; /* physical starting address of memory chunk */
unsigned long start_addr; /* starting address of memory chunk */
unsigned long end_addr; /* ending address of memory chunk */
unsigned long bits[0]; /* bitmap for allocating memory chunk */
};
extern struct gen_pool *gen_pool_create(int, int);
-extern int gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
+extern unsigned long gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long);
+extern int gen_pool_add_virt(struct gen_pool *, unsigned long, unsigned long,
+ size_t, int);
+/**
+ * gen_pool_add - add a new chunk of special memory to the pool
+ * @pool: pool to add new memory chunk to
+ * @addr: starting address of memory chunk to add to pool
+ * @size: size in bytes of the memory chunk to add to pool
+ * @nid: node id of the node the chunk structure and bitmap should be
+ * allocated on, or -1
+ *
+ * Add a new chunk of special memory to the specified pool.
+ */
+static inline int gen_pool_add(struct gen_pool *pool, unsigned long addr,
+ size_t size, int nid)
+{
+ return gen_pool_add_virt(pool, addr, 0, size, nid);
+}
extern void gen_pool_destroy(struct gen_pool *);
extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 1923f14..83b069b 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -39,17 +39,18 @@ struct gen_pool *gen_pool_create(int min_alloc_order, int nid)
EXPORT_SYMBOL(gen_pool_create);
/**
- * gen_pool_add - add a new chunk of special memory to the pool
+ * gen_pool_add_virt - add a new chunk of special memory to the pool
* @pool: pool to add new memory chunk to
- * @addr: starting address of memory chunk to add to pool
+ * @virt: virtual starting address of memory chunk to add to pool
+ * @phys: physical starting address of memory chunk to add to pool
* @size: size in bytes of the memory chunk to add to pool
* @nid: node id of the node the chunk structure and bitmap should be
* allocated on, or -1
*
* Add a new chunk of special memory to the specified pool.
*/
-int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
- int nid)
+int gen_pool_add_virt(struct gen_pool *pool, unsigned long virt, unsigned long phys,
+ size_t size, int nid)
{
struct gen_pool_chunk *chunk;
int nbits = size pool-min_alloc_order;
@@ -61,8 +62,9 @@ int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
return -1;
spin_lock_init(chunk-lock);
- chunk-start_addr = addr;
- chunk-end_addr = addr + size;
+ chunk-phys_addr = phys;
+ chunk-start_addr = virt;
+ chunk-end_addr = virt + size;
write_lock(pool-lock);
list_add(chunk-next_chunk, pool-chunks);
@@ -70,7 +72,30 @@ int gen_pool_add(struct gen_pool *pool, unsigned long addr, size_t size,
return 0;
}
-EXPORT_SYMBOL(gen_pool_add);
+EXPORT_SYMBOL(gen_pool_add_virt);
+
+/**
+ * gen_pool_virt_to_phys - return the physical address of memory
+ * @pool: pool to allocate from
+ * @addr: starting address of memory
+ */
+unsigned long gen_pool_virt_to_phys(struct gen_pool *pool, unsigned long addr)
+{
+ struct list_head *_chunk;
+ struct gen_pool_chunk *chunk;
+
+ read_lock(pool-lock);
+ list_for_each(_chunk, pool-chunks) {
+ chunk = list_entry(_chunk, struct gen_pool_chunk, next_chunk);
+
+ if (addr = chunk-start_addr addr chunk-end_addr)
+ return chunk-phys_addr + addr - chunk-start_addr;
+ }
+ read_unlock(pool-lock
Re: [RFC PATCH v2] Consolidate SRAM support
On 00:20 Wed 20 Apr , Russell King - ARM Linux wrote: On Tue, Apr 19, 2011 at 09:05:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 17:18 Tue 19 Apr , Russell King - ARM Linux wrote: On Tue, Apr 19, 2011 at 06:01:35PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: Hi, I do post a patch to add the support to specify a virt and phys address to the generic allocator so the pv-pool.c is not needed we can just use the generic fucntion You've talked about this before in the thread, but the patch never appeared. I forget to re-send it sorry it's the mm tree One obvious issue here is that you're using 'unsigned long' for phys addresses. With LPAE we could start seeing SRAM outside of the 4GB PA range, and so would need this to be phys_addr_t. I'll update it any other issue? Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Consolidate SRAM support
On 14:06 Fri 15 Apr , Russell King - ARM Linux wrote:
This is work in progress.
We have two SoCs using SRAM, both with their own allocation systems,
and both with their own ways of copying functions into the SRAM.
Let's unify this before we have additional SoCs re-implementing this
obviously common functionality themselves.
Unfortunately, we end up with code growth through doing this, but that
will become a win when we have another SoC using this (which I know
there's at least one in the pipeline).
One of the considerations here is that we can easily convert sram-pool.c
to hook into device tree stuff, which can tell the sram allocator:
- physical address of sram
- size of sram
- allocation granularity
and then we just need to ensure that it is appropriately mapped.
This uses the physical address, and unlike Davinci's dma address usage,
it always wants to have the physical address, and will always return
the corresponding physical address when passed that pointer.
OMAP could probably do with some more work to make the omapfb and other
allocations use the sram allocator, rather than hooking in before the
sram allocator is initialized - and then further cleanups so that we
have an initialization function which just does
sram_create(phys, size)
virt = map sram(phys, size)
create sram pool(virt, phys, size, min_alloc_order)
Another question is whether we should allow multiple SRAM pools or not -
this code does allow multiple pools, but so far we only have one pool
per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate
it if they want to partition the SRAM, or have peripheral-local SRAMs.
Lastly, uio_pruss should probably take the SRAM pool pointer via
platform data so that it doesn't have to include Davinci specific
includes.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Hi,
I also work on it for at91
and already have some patch in the mm for this
[PATCH] genalloc: add support to specify the physical address
so now you can do this
as I do on at91 will send the patch after
static struct map_desc at91sam9g20_sram_desc[] __initdata = {
{
.virtual= AT91_IO_VIRT_BASE - AT91SAM9G20_SRAM_SIZE,
.pfn= __phys_to_pfn(AT91SAM9G20_SRAM_BASE),
.length = AT91SAM9G20_SRAM_SIZE,
.type = MT_DEVICE,
}
};
sram_pool = gen_pool_create(2, -1);
gen_pool_add_virt(sram_pool, io_desc-virtual
__pfn_to_phys(io_desc-pfn),
io_desc-length, -1)
and to get the physical address
phys = gen_pool_virt_to_phys(sram_pool, virt);
Best Resgards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On 17:30 Fri 01 Apr , Detlef Vollmann wrote: On 04/01/11 16:59, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. In the ARM tree I only know mach-at91. Atmel still introduces new SOCs based on ARM926EJ-S, and that makes perfect sense for lots of applications. And if they add support for a new SOC, they just copy an existing one, change some GPIOs, and submit it as new files (sorry, I'm over- simplifying here). at SoC level quite a lot as we do the necessarly to factorise as much as we can you can take a look when we add the g20, g10 of g45, etc... And if you happen to wire your board a bit differently than they do, you have to patch theur generic file (in addidtion to add your own board file). And though I only know the mach-at91 closely, I'm pretty sure quite a number of other mach-* are not better. So this is actually why the ARM tree has such a bad reputation: lot's of code repetition, and still more of that. On AT91 it's not anymore the case now we do start reduce the number of machine and we not allow this anymore 12. Supporting many different boards with a single kernel binary is a useful goal. Generally not for embedded systems (for me, a mobile PDA/phone is just a small computer with a crappy keyboard, but not an embedded system). True. For embedded, this would not be an important thing to do, but also not hurt. It costs you flash space. I disagree have a single kernel with mutliple board is very usefull as it can allow you to have one firmware for multiple version of product. It will really simplify the maintanance And it's also allow to simplify kernel maintanance * Strictly no crap * No board files Where do you put code that needs to run very early (e.g. pinging the watchdog)? Don't know. I'd hope we can get fast enough to the phase where device drivers get initialized. Nope, never happened for me :-( (Watchdog timeouts are often 1s or less.) you can do a lot in 1s you start the board dowload the code from nfs and jump in the kernel as I do on at91sam9261ek with barebox * All board specific information must come from a device tree and be run-time detected. What do you mean by run-time detected? For powerpc, we currently have the device tree as DTS in the kernel and compile and bundle it together with the kernel. As you wrote above: Discoverable hardware [...] is not going to happen I mean writing if (device_is_compatible(dev, SOMETHING)) do_something(); instead of #ifdef CONFIG_SOMETHING do_something(); #endif The run-time information could come from anywhere (device tree, hardware registers, today one might use the board number), the important point is not to assume that hardware is present just because someone enabled a Kconfig option. Understood and I agree. I believe that rule is generally accepted today, but we don't always enforce it. Without device tree, Kconfig option is the only way that really works today (no runtime HW detection, and same board ID with different setups). you can do it already today with system_rev DTS will allow to make it more generic and pass more information and on at91 we could easly have only few boards. Except for few case such as really short boottime requirement this will not impact the system on contrary Best Regards, J. Device tree in my world is just one big Kconfig option instead of many small... Detlef ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On 11:50 Thu 31 Mar , Russell King - ARM Linux wrote: On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote: If I boot it on a current PC I'm booting on a multiprocessor system with different timers, totally different IRQ controllers, different keyboard controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics running in shared host memory able to give/take pages from the host, extra instructions, etc etc And the same kernel boots just fine on both just fine. We've been there for a long time with ARM. Right from the start I had a single kernel image which booted over a range of ARM CPUs and platforms. As far as ARM CPU architectures go, today we can have a single kernel image which covers ARMv3 to ARMv5, and a separate kernel image which covers ARMv6 to ARMv7 including SMP and UP variants. The thing which currently stops ARMv3 to ARMv7 all together is the different page table layouts, the ASID tagging, the exclusive load/store support for cmpxchg and other atomic operations, etc. As we can see a lots of people work on this, to now do not add thousand of boards but try to have only a few Personnaly I do it on at91 as example and will continue to try to have one board in the kernel with board information pass via Barebox, when it's possible. I think it's a common effort doen by the ARM Community and this will imply a lots of changesets. The work done by Linaro with the device tree will help a lot to simplify the pass of the information from the boot loader to the kernel. But we can already do it today. Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
