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 > 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"
> >>>> Cc: Tony Lindgren
> >>>> Cc: Russell King
> >>>> 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
> >>>> ---
> >>>> 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 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: [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
> >> ---
> >> 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 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
> >> ---
> >> 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 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
> ---
> 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 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
> ---
> 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 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
> ---
> 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: [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"
> >> Cc: Tony Lindgren
> >> Cc: Russell King
> >> 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
> >> ---
> >> 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
> ---
> 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 > > 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 > 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 > 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-i2c&m=134986995731695&w=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 > > 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 Best Regards, J. > Signed-off-by: Xiao Jiang > --- > 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
> Signed-off-by: Santosh Shilimkar
> ---
> 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 12:55 Fri 04 May , Stephen Warren wrote:
> On 05/04/2012 10:34 AM, Tony Lindgren wrote:
> > * Jean-Christophe PLAGNIOL-VILLARD [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
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 [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 08:03 Fri 04 May , Tony Lindgren wrote:
> * Jean-Christophe PLAGNIOL-VILLARD [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 MU
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 [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] 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
> ---
> 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_PU
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 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 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 > Cc: Andrew Victor > Cc: Nicolas Ferre > Cc: Jean-Christophe Plagniol-Villard > Cc: Russell King > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: Kukjin Kim > Cc: Sascha Hauer > Cc: Shawn Guo > Cc: Lennert Buytenhek > Cc: Nicolas Pitre > Cc: Eric Miao > Cc: Haojian Zhuang > Cc: David Brown > Cc: Daniel Walker > Cc: Bryan Huntsman > Cc: Tony Lindgren > Cc: Barry Song > Cc: Andrew Lunn > Cc: Lucas De Marchi > 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 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 [22 03:30]:
> > > On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> > > wrote:
> > > > On 17 November 2011 19:27, Linus Walleij
> > > > 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
Re: [PATCH 1/7] amp/remoteproc: add framework for controlling remote processors
On 11:48 Tue 25 Oct , Ohad Ben-Cohen wrote: > Modern SoCs typically employ a central symmetric multiprocessing (SMP) > application processor running Linux, with several other asymmetric > multiprocessing (AMP) heterogeneous processors running different instances > of operating system, whether Linux or any other flavor of real-time OS. > > Booting a remote processor in an AMP configuration typically involves: > - Loading a firmware which contains the OS image > - Allocating and providing it required system resources (e.g. memory) > - Programming an IOMMU (when relevant) > - Powering on the device > > This patch introduces a generic framework that allows drivers to do > that. In the future, this framework will also include runtime power > management and error recovery. > > Based on (but now quite far from) work done by Fernando Guzman Lugo > . > > ELF loader was written by Mark Grosen , based on > msm's Peripheral Image Loader (PIL) by Stephen Boyd . > > Designed with Brian Swetland . > > Signed-off-by: Ohad Ben-Cohen > Cc: Brian Swetland > Cc: Arnd Bergmann > Cc: Grant Likely > Cc: Tony Lindgren > Cc: Russell King > Cc: Rusty Russell > Cc: Andrew Morton > Cc: Greg KH > Cc: Stephen Boyd > --- > Documentation/amp/remoteproc.txt | 324 ++ > MAINTAINERS |7 + > drivers/Kconfig |2 + > drivers/Makefile |1 + > drivers/amp/Kconfig |9 + > drivers/amp/Makefile |1 + > drivers/amp/remoteproc/Kconfig |3 + > drivers/amp/remoteproc/Makefile |6 + > drivers/amp/remoteproc/remoteproc_core.c | 1410 > ++ > drivers/amp/remoteproc/remoteproc_internal.h | 44 + > include/linux/amp/remoteproc.h | 265 + > 11 files changed, 2072 insertions(+), 0 deletions(-) > create mode 100644 Documentation/amp/remoteproc.txt > create mode 100644 drivers/amp/Kconfig > create mode 100644 drivers/amp/Makefile > create mode 100644 drivers/amp/remoteproc/Kconfig > create mode 100644 drivers/amp/remoteproc/Makefile > create mode 100644 drivers/amp/remoteproc/remoteproc_core.c > create mode 100644 drivers/amp/remoteproc/remoteproc_internal.h > create mode 100644 include/linux/amp/remoteproc.h > > diff --git a/Documentation/amp/remoteproc.txt > b/Documentation/amp/remoteproc.txt > new file mode 100644 > index 000..63cecd9 > --- /dev/null > +++ b/Documentation/amp/remoteproc.txt > @@ -0,0 +1,324 @@ > +Remote Processor Framework > + > +1. Introduction > + > +Modern SoCs typically have heterogeneous remote processor devices in > asymmetric > +multiprocessing (AMP) configurations, which may be running different > instances > +of operating system, whether it's Linux or any other flavor of real-time OS. > + > +OMAP4, for example, has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP. > +In a typical configuration, the dual cortex-A9 is running Linux in a SMP > +configuration, and each of the other three cores (two M3 cores and a DSP) > +is running its own instance of RTOS in an AMP configuration. > + > +The remoteproc framework allows different platforms/architectures to > +control (power on, load firmware, power off) those remote processors while > +abstracting the hardware differences, so the entire driver doesn't need to be > +duplicated. In addition, this framework also adds rpmsg virtio devices > +for remote processors that supports this kind of communication. This way, > +platform-specific remoteproc drivers only need to provide a few low-level > +handlers, and then all rpmsg drivers will then just work > +(for more information about the virtio-based rpmsg bus and its drivers, > +please read Documentation/amp/rpmsg.txt). > + > +2. User API > + > + int rproc_boot(struct rproc *rproc) > +- Boot a remote processor (i.e. load its firmware, power it on, ...). > + If the remote processor is already powered on, this function > immediately > + returns (successfully). > + Returns 0 on success, and an appropriate error value otherwise. > + Note: to use this function you should already have a valid rproc > + handle. There are several ways to achieve that cleanly (devres, pdata, > + the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, we > + might also consider using dev_archdata for this). See also > + rproc_get_by_name() below. > + > + void rproc_shutdown(struct rproc *rproc) > +- Power off a remote processor (previously booted with rproc_boot()). > + In case @rproc is still being used by an additional user(s), then > + this function will just decrement the power refcount and exit, > + without really powering off the device. > + Every call to rproc_boot() must (eventually) be accompanied by a call > + to rproc_shutdown(). Calling rproc_shutdown() redundantly is a bug. > +
[RFC PATCH v4] Consolidate SRAM support
From: Russell King - ARM Linux
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
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: Tony Lindgren
Cc: Sascha Hauer
---
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 = &dm644x_emac_pdata,
- .sram_dma
Re: [PATCH 00/14] GPIO: OMAP: first round of cleanup
On 17:14 Fri 20 May , Kevin Hilman wrote: > Start moving SoC-specific register handling out of the driver by passing > in register offsets in via platform data. > > Also, move OMAP1 MPUIO IRQ handling over to genric IRQ chip. > > Applies on top of Tony's for-next branch (which include's the generic > IRQ chip work from tglx) and the OMAP GPIO driver move to > drivers/gpio. > > Charulatha V (1): > GPIO: OMAP: remove get_gpio_bank() > > Kevin Hilman (13): > GPIO: OMAP: _clear_gpio_irqbank: fix flushing of posted write > GPIO: OMAP: remove MPUIO handling from _clear_gpio_irqbank() > GPIO: OMAP: move bank width into struct gpio_bank > GPIO: OMAP: _get_gpio_irqbank_mask: replace hard-coded mask with > bank->width > GPIO: OMAP: replace get_gpio_index() by using bank width > GPIO: OMAP: consolidate direction, input, output, remove #ifdefs > GPIO: OMAP: consolidate IRQ status handling, remove #ifdefs > GPIO: OMAP: conslidate enable/disable of GPIO IRQs, remove ifdefs > GPIO: OMAP: convert MPUIO IRQ over to generic irq_chip > GPIO: OMAP: remove useless gpio_valid() & check_gpio() checks > GPIO: OMAP: cleanup _set_gpio_wakeup(), remove ifdefs > GPIO: OMAP: debounce remove SoC specific registers, use pdata > GPIO: OMAP: cleanup show revision, remove cpu_is checks, display only > once looks good 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 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 > --- > > 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
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 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
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
---
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 >=
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
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +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
> +
> +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
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
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
