Re: [PATCH 1/4 v6] drivers: create a pin control subsystem v6
[I know Stephen is on vacation, just stacking up some nice reading for when he gets back and for others to enjoy] On Fri, Sep 2, 2011 at 6:33 PM, Stephen Warren wrote: > Linus Walleij wrote at Friday, September 02, 2011 6:59 AM: >> >> diff --git a/include/linux/pinctrl/pinmux.h >> >> b/include/linux/pinctrl/pinmux.h >> > >> >> +/** >> >> + * struct pinmux_ops - pinmux operations, to be implemented by pin >> >> controller >> >> + * drivers that support pinmuxing >> >> + * @request: called by the core to see if a certain pin can be made >> >> available >> >> + * available for muxing. This is called by the core to acquire the pins >> >> + * before selecting any actual mux setting across a function. The >> >> driver >> >> + * is allowed to answer "no" by returning a negative error code >> >> + * @free: the reverse function of the request() callback, frees a pin >> >> after >> >> + * being requested >> > >> > Shouldn't request/free be for a pingroup, not a pin, since that's what >> > functions are assigned to? Also, the function should be passed, since >> > some restrictions these functions might need to check for might depend >> > on what the pin/group will be used for. >> >> This is not for checking anything on function or group level. >> It's exclusively for things that need to be on a per-pin level, so any >> pin can deny being selected for muxing at any time. >> >> So what you're saying is that you need a function to check >> also on group level as part of the pinmux_get() sematics? >> >> We can add that and have two optional checks: @request_pin() >> on pin level and say @request_function_and_group() on the >> group+function level, would that work for your scenarios? > > Well, that's a move in the right direction, but not quite everything I'd > like. > > The basic issue is that a single logical function (I2C controller 0) can > be mux'd out onto more than one pingroup. However, the HW requires that > at /any given time/ it only be mux'd out onto a single pingroup. > > To fully enforce this, the request() function needs to know what the > complete state will be after the entire (set of) mapping entries is > processed. I'm not quite following this, but I'm pretty sure that this verification can be bolted onto the subsystem later with apropriate callbacks. It looks like you're after a state holder to avoid pinmux_get() to activate the same muxing in two different places, it's then a safety mechanism agains supplying bad mappings and doing pinmux_get() on stuff before doing pinmux_put() on conflicting mappings. > When the core can only process 1 mapping entry at a time, this is trivial, > since there's only 1 change relative to current HW to process in request(). You will have this in v7 :-) I was aware that this would cause new semantic issues, but since I think only Tegra will use that feature as of now, we can postpone this group denial stuff until there is a driver for it I think, it shouldn't be too hard to add, and you can still get the driver to a working state, it's just that it'll be possible to do some nasty things with it if you give it weird mapping tables and calls. > The only way I can see this being implementable is: > > a) Add request_start() and request_end() functions, so the driver can > copy HW state to SW state in request_start(), and modify this cached > state in each request() call, and hence has access to all state changes > to-date in each request() call. Then, request_end() to finalize the > whole set of changes. > > Or: > > b) request() passes an array of changes at once, instead of many calls > each requesting a single .change > > This is certainly a tough problem. The current Tegra pinmux driver doesn't > actually make any attempt to enforce this, so perhaps it's not worth > worrying about; we just assume people write sensible mapping tables. Ok we are at that stage with the subsystem now so let's wait with that until we have a driver we can fix. >> > When the core is modified to support applying n entries in the mapping >> > table for each pinmux_get() call, how will request/free be aware of the >> > partial pending state? >> >> That is like answering how code I haven't yet written will >> look like... The easiest answer is to implement it I think, >> then you can check if it looks sane. > > :-) As it is implemented now it backs off and free all pins if there is an error on any group when doing pinmux_get(). Yours, Linus Walleij ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/6] drm/i915: use common functions for mmap offset creation
On Mon, Sep 12, 2011 at 02:21:22PM -0500, Rob Clark wrote: > From: Rob Clark > > Signed-off-by: Rob Clark Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 5/6] drm/i915: use common functions for get/put pages
On Mon, Sep 12, 2011 at 02:21:25PM -0500, Rob Clark wrote: > From: Rob Clark > > Signed-off-by: Rob Clark Reviewed-by: Daniel Vetter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ACTIVITY] OCTO status report - wk36.2011 (20110905-20110909)
Status: https://wiki.linaro.org/OfficeofCTO/WeeklyReport Last meeting minutes: https://wiki.linaro.org/OfficeofCTO/2011-09-06 Highlights: - regarding 1109 work is progressing - details are in the status link above. The only item which may not be completed during 1109 is the runtime linker patches. The build farm was put together by Steve McIntyre (see http://blog.einval.com/2011/09/05#armhf_buildds for some details). - Mozilla discussions are ongoing - Loïc has provided some feedback on what is the preliminary scope, involving two potential threads : (performance optimised) Firefox on Android, and boot-to-gecko. Both seem to be areas where Linaro could contribute. - UMM work is progressing. Documentation is becoming available through presentations (see in https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFile&do=view&target=CMA.pdf and https://wiki.linaro.org/OfficeofCTO/MemoryManagement?action=AttachFile&do=view&target=DMA_Buffer.pdf). Also there is material also from the Linux Plumbers in http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/tracks/117. - Also this coming week we will resume the Boot Architecture discussions. Best, -- Ilias Biris ilias.bi...@linaro.org Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[ANN] Daily seeded builds of Android toolchain from gcc-linaro bzr
Hello, There're now regular builds of Android 4.5 and 4.6 toolchains from gcc-linaro bzr repository. These builds will allow Android team to track Toolchain WG progress closer, be more prepared to toolchain release, and later - to do CI tests using it. 4.6 toolchain, which is the scope of the current development and which is used to build Linaro Android release, is build daily. 4.5 toolchain which is stable and apparently heads towards maintenance release only, built twice a week (Wed & Fri), to optimize utilization of pay-per-usage EC2 resources. https://android-build.linaro.org/builds/~linaro-android/toolchain-4.5-bzr/ https://android-build.linaro.org/builds/~linaro-android/toolchain-4.6-bzr/ Thanks to Michael Hope's help, these builds use repository tarball seeds to initialize bzr checkouts, and so both fast and optimal in network bandwidth. The seed itself is available in S3: http://s3.amazonaws.com/gcc-linaro/lp-gcc-linaro-seed-bzr106808.tar.xz and can be reused by other EC2-hosted projects to leverage optimal resource usage practices. More info on how to use it can be found in Michael's writeup at: https://wiki.linaro.org/WorkingGroups/ToolChain/BzrSeeds -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux
On Fri, Sep 2, 2011 at 6:04 PM, Stephen Warren wrote:
> Linus Walleij wrote at Friday, September 02, 2011 2:12 AM:
>> On Thu, Sep 1, 2011 at 11:33 PM, Stephen Warren wrote:
>>
>> >> +static const struct u300_pmx_func u300_pmx_functions[] = {
>> >> + {
>> >> + .name = "power",
>> >> + .groups = { POWERGRP_INDEX },
>> >> + /* Mask is N/A */
>> >> + },
>> >
>> > Hmmm. That's a lot of _INDEX defines that'd need to be set up, at least
>> > to fully represent a chip like Tegra. Can the pinmux core be modified
>> > such that the group list is an array of names (char*) rather than the
>> > actual numeric IDs of the groups? Still, perhaps we could use the enum
>> > we already have for this, so perhaps it isn't a big deal...
>>
>> Well I could think about a lot of ways to do this, but it's basically up
>> to the driver, the U300 is just some simple example of what you can
>> do, it's just trying to satisfy the API.
>>
>> Maybe as part of writing the nVidia driver you find a clever
>> mechanism for doing this, if it's looking generally useful at that
>> point then let's move it to the core I'd say.
>
> The reason I asked about the pinmux core handling this is because the
> driver op get_function_groups:
>
> + int (*get_function_groups) (struct pinctrl_dev *pctldev,
> + unsigned selector,
> + unsigned ** const groups,
> + unsigned * const num_groups);
>
> returns an array of integer indexes. I think the only way to get rid of
> the index definitions in the drivers is to allow get_function_groups to
> return an array of strings instead.
OK good idea, I reworked this interface to get an array of strings
instead, I've been told several times to use strings rather than numbers
when possible, so I think this is the right thing to do.
Check it out in v7!
Yours,
Linus Walleij
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9 2/3] mmc: core: add random fault injection
2011/8/19 Per Forlin :
> +#ifdef KERNEL
> +/*
> + * Internal function. Pass the boot param fail_mmc_request to
> + * the setup fault injection attributes routine.
> + */
> +static int __init setup_fail_mmc_request(char *str)
> +{
> + return setup_fault_attr(&fail_mmc_request, str);
> +}
> +__setup("fail_mmc_request=", setup_fail_mmc_request);
> +#endif /* KERNEL */
You attempt to enable __setup() only when mmc_core is built into
the kernel. Does it really work? I cannot find any drivers using
"KERNEL" macro.
You can use module_param_cb() instead of __setup() without #ifdef KERNEL.
When mmc_core is built into the kernel, you can specify the parameter
with "mmc_core.fail_mmc_request=..."
Sorry for pointing that out too late.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9 2/3] mmc: core: add random fault injection
On 13 September 2011 15:12, Akinobu Mita wrote:
> 2011/8/19 Per Forlin :
>
>> +#ifdef KERNEL
>> +/*
>> + * Internal function. Pass the boot param fail_mmc_request to
>> + * the setup fault injection attributes routine.
>> + */
>> +static int __init setup_fail_mmc_request(char *str)
>> +{
>> + return setup_fault_attr(&fail_mmc_request, str);
>> +}
>> +__setup("fail_mmc_request=", setup_fail_mmc_request);
>> +#endif /* KERNEL */
>
> You attempt to enable __setup() only when mmc_core is built into
> the kernel. Does it really work? I cannot find any drivers using
> "KERNEL" macro.
>
Your right it doesn't work. I think I change from ifndef MODULE to
ifdef KERNEL at one point.
It should be "ifndef MODULE"
> You can use module_param_cb() instead of __setup() without #ifdef KERNEL.
> When mmc_core is built into the kernel, you can specify the parameter
> with "mmc_core.fail_mmc_request=..."
>
Thanks, this is the proper way to do it.
> Sorry for pointing that out too late.
>
I think this patch is queued for 3.2 so there should be time to fix it still.
Thanks again,
Per
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9 2/3] mmc: core: add random fault injection
Hi Akinobu,
On 13 September 2011 16:19, Per Forlin wrote:
> On 13 September 2011 15:12, Akinobu Mita wrote:
>> 2011/8/19 Per Forlin :
>>
>>> +#ifdef KERNEL
>>> +/*
>>> + * Internal function. Pass the boot param fail_mmc_request to
>>> + * the setup fault injection attributes routine.
>>> + */
>>> +static int __init setup_fail_mmc_request(char *str)
>>> +{
>>> + return setup_fault_attr(&fail_mmc_request, str);
>>> +}
>>> +__setup("fail_mmc_request=", setup_fail_mmc_request);
>>> +#endif /* KERNEL */
>>
>> You attempt to enable __setup() only when mmc_core is built into
>> the kernel. Does it really work? I cannot find any drivers using
>> "KERNEL" macro.
>>
> Your right it doesn't work. I think I change from ifndef MODULE to
> ifdef KERNEL at one point.
> It should be "ifndef MODULE"
>
>> You can use module_param_cb() instead of __setup() without #ifdef KERNEL.
>> When mmc_core is built into the kernel, you can specify the parameter
>> with "mmc_core.fail_mmc_request=..."
>>
I am considering using module_param() with perm = 0 (not visible in
sysfs). The purpose of the param is to set fault attributes during
kerne boot time or module load time. After the kernel boot all can be
set under debug fs, therefore no need to make the module param
visible.
What do you think about this? I have not tested it yet.
--
+++ b/drivers/mmc/core/debugfs.c
@@ -20,6 +20,14 @@
#include "core.h"
#include "mmc_ops.h"
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+static DECLARE_FAULT_ATTR(fail_mmc_default_attr);
+static char *fail_mmc_request;
+module_param(fail_mmc_request, charp, 0);
+
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
/* The debugfs functions are optimized away when CONFIG_DEBUG_FS isn't set. */
static int mmc_ios_show(struct seq_file *s, void *data)
{
@@ -159,23 +167,6 @@ static int mmc_clock_opt_set(void *data, u64 val)
return 0;
}
-#ifdef CONFIG_FAIL_MMC_REQUEST
-
-static DECLARE_FAULT_ATTR(fail_mmc_request);
-
-#ifdef KERNEL
-/*
- * Internal function. Pass the boot param fail_mmc_request to
- * the setup fault injection attributes routine.
- */
-static int __init setup_fail_mmc_request(char *str)
-{
- return setup_fault_attr(&fail_mmc_request, str);
-}
-__setup("fail_mmc_request=", setup_fail_mmc_request);
-#endif /* KERNEL */
-#endif /* CONFIG_FAIL_MMC_REQUEST */
-
DEFINE_SIMPLE_ATTRIBUTE(mmc_clock_fops, mmc_clock_opt_get, mmc_clock_opt_set,
"%llu\n");
@@ -207,7 +198,9 @@ void mmc_add_host_debugfs(struct mmc_host *host)
goto err_node;
#endif
#ifdef CONFIG_FAIL_MMC_REQUEST
- host->fail_mmc_request = fail_mmc_request;
+ if (fail_mmc_request)
+ setup_fault_attr(&fail_mmc_default_attr, fail_mmc_request);
+ host->fail_mmc_request = fail_mmc_default_attr;
if (IS_ERR(fault_create_debugfs_attr("fail_mmc_request",
root,
&host->fail_mmc_request)))
--
It's only necessary to call setup_fault_attr() once for all hosts.
Here it's called one time for each host. I think it's ok since the
routine is small and used for debugging purposes.
I could use a static bool to indicate whether setup_fault_attr() has
already been issued.
+ if (fail_mmc_request && !setup_fault_attr_done)
Regards,
Per
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH] mmc: sdio: rw extended, use a sg entry for each block
Le 07/09/2011 13:40, Nicolas Ferre :
> While using io multiple blocks operations, change the way that sg is built:
> use one sg entry for each block instead of aggregating the whole buffer
> in a single sg entry.
> Using a single sg entry for a multiple block command may lead to
> misunderstanding between the sd/mmc and the DMA controllers. In fact, the
> knowledge of the block length will allow both controllers to optimize burst
> sizes on internal bus while dealing with those data.
>
> Use a sg table to store start addresses of blocks within the data buffer.
Ping?
I add linaro-dev so maybe other people can be interested...
> Signed-off-by: Nicolas Ferre
> ---
> drivers/mmc/core/sdio_ops.c | 38 +-
> 1 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio_ops.c b/drivers/mmc/core/sdio_ops.c
> index f087d87..aea6978 100644
> --- a/drivers/mmc/core/sdio_ops.c
> +++ b/drivers/mmc/core/sdio_ops.c
> @@ -124,7 +124,7 @@ int mmc_io_rw_extended(struct mmc_card *card, int write,
> unsigned fn,
> struct mmc_request mrq = {0};
> struct mmc_command cmd = {0};
> struct mmc_data data = {0};
> - struct scatterlist sg;
> + struct sg_table sgt;
>
> BUG_ON(!card);
> BUG_ON(fn > 7);
> @@ -144,24 +144,44 @@ int mmc_io_rw_extended(struct mmc_card *card, int
> write, unsigned fn,
> cmd.arg |= fn << 28;
> cmd.arg |= incr_addr ? 0x0400 : 0x;
> cmd.arg |= addr << 9;
> - if (blocks == 1 && blksz <= 512)
> - cmd.arg |= (blksz == 512) ? 0 : blksz; /* byte mode */
> - else
> - cmd.arg |= 0x0800 | blocks; /* block mode */
> + if (blocks == 1 && blksz <= 512) {
> + /* byte mode */
> + struct scatterlist sg;
> +
> + cmd.arg |= (blksz == 512) ? 0 : blksz;
> + sg_init_one(&sg, buf, blksz * blocks);
> +
> + data.sg = &sg;
> + data.sg_len = 1;
> + } else {
> + /* block mode */
> + struct scatterlist *sg_ptr;
> + int i;
> +
> + cmd.arg |= 0x0800 | blocks;
> + if (sg_alloc_table(&sgt, blocks, GFP_KERNEL))
> + return -ENOMEM;
> + for_each_sg(sgt.sgl, sg_ptr, sgt.nents, i) {
> + sg_set_buf(sg_ptr, buf + i * blksz, blksz);
> + }
> +
> + data.sg = sgt.sgl;
> + data.sg_len = sgt.nents;
> + }
> +
> cmd.flags = MMC_RSP_SPI_R5 | MMC_RSP_R5 | MMC_CMD_ADTC;
>
> data.blksz = blksz;
> data.blocks = blocks;
> data.flags = write ? MMC_DATA_WRITE : MMC_DATA_READ;
> - data.sg = &sg;
> - data.sg_len = 1;
> -
> - sg_init_one(&sg, buf, blksz * blocks);
>
> mmc_set_data_timeout(&data, card);
>
> mmc_wait_for_req(card->host, &mrq);
>
> + if (blocks != 1 || blksz > 512)
> + sg_free_table(&sgt);
> +
> if (cmd.error)
> return cmd.error;
> if (data.error)
Best regards,
--
Nicolas Ferre
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Cortex-A Programmer's Guide
I think that has one of the clearest "Booting Linux" sections (13.3) I've ever read. -Zach On 8 September 2011 11:22, Christian Robottom Reis wrote: > - Forwarded message from Roger Teague - > > Date: Wed, 7 Sep 2011 14:25:11 +0100 > From: Roger Teague > Subject: Cortex Programmers Guide > > Folks, > > Are you aware of the following? > > http://www.cadence.com/Community/blogs/sd/archive/2011/08/04/a-must-read-the-arm-cortex-a-programmer-s-guide.aspx > > a blog from Cadence but it does carry a link to the doc. > > - End forwarded message - > > Enjoy! > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball
On Mon, Sep 12, 2011 at 10:12:22PM -0500, Zach Pfeffer wrote: > stage-origen-11.09-release > stage-panda-11.09-release > stage-snowball-11.09-release > stage-imx53-11.09-release > panda-11.09-release > beagle-11.09-release > > Would be: > > origen-staging-11.09-taupe > panda-staging-11.09-mauve > snowball-staging-11-burntsienna > imx53-staging-11.09-orangecrush > panda-11.09-crucialpink > beagle-11.09-black The main problem I see with staging is that it's simply not true in the common sense of the word staging -- it implies that what is in staging today is intended to become upstream (or "mainstream") in the future, whereas there's lots that is in the LT branches which, well, isn't. OTOH, I really can't come up with good alternatives to 'staging' that I don't see other problems with. There was a "non-upstreamable" suggestion a while back, and I have been known to call them "dirty" ;-) -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball
On Tue, 13 Sep 2011 15:16:00 -0300, Christian Robottom Reis wrote: > The main problem I see with staging is that it's simply not true in the > common sense of the word staging -- it implies that what is in staging > today is intended to become upstream (or "mainstream") in the future, > whereas there's lots that is in the LT branches which, well, isn't. > > OTOH, I really can't come up with good alternatives to 'staging' that I > don't see other problems with. There was a "non-upstreamable" suggestion > a while back, and I have been known to call them "dirty" ;-) What about taking a cue from gstreamer? good, bad and ugly I don't think we have the same division of them, but "ugly" could work, in a similar spirit to "dirty," but without some of the implications? Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball
On Tue, Sep 13, 2011, James Westby wrote: > What about taking a cue from gstreamer? > good, bad and ugly > I don't think we have the same division of them, but "ugly" could work, > in a similar spirit to "dirty," but without some of the implications? [ The names of course come from the movie, but sometimes GStreamer folks regretted picking these names because end-users didn't really understand why they should run something "bad" or even "ugly". ] -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: First 11.09 Linaro Android Candidate Builds are done for (Linux 3.0.3, GCC 4.6, libjpegturbo) Panda, Beagle, Beagle xM, iMX53, Origen, Snowball
On 13 September 2011 15:21, Loïc Minier wrote: > On Tue, Sep 13, 2011, James Westby wrote: >> What about taking a cue from gstreamer? >> good, bad and ugly >> I don't think we have the same division of them, but "ugly" could work, >> in a similar spirit to "dirty," but without some of the implications? > > [ The names of course come from the movie, but sometimes GStreamer > folks regretted picking these names because end-users didn't really > understand why they should run something "bad" or even "ugly". ] I agree. I really don't like to use the terms bad or ugly to describe work. I think it sets the wrong tone. It sounds like staging is generally okay with people. I tend to take the view that its always possible to upstream the outstanding patches, though it may not be likely - the glass is half full, right? > > -- > Loďc Minier > -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/3] mmc: add module param to set fault injection attributes
Replace setup("fail_mmc_request") and faulty "ifdef KERNEL" with
a simple module_param(). The module param mmc_core.fail_request
may be used to set the fault injection attributes during boot time
or module load time.
Signed-off-by: Per Forlin
---
drivers/mmc/core/debugfs.c | 29 +++--
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 5acd707..bb72ba2 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -20,6 +20,14 @@
#include "core.h"
#include "mmc_ops.h"
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+static DECLARE_FAULT_ATTR(fail_default_attr);
+static char *fail_request;
+module_param(fail_request, charp, 0);
+
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
/* The debugfs functions are optimized away when CONFIG_DEBUG_FS isn't set. */
static int mmc_ios_show(struct seq_file *s, void *data)
{
@@ -159,23 +167,6 @@ static int mmc_clock_opt_set(void *data, u64 val)
return 0;
}
-#ifdef CONFIG_FAIL_MMC_REQUEST
-
-static DECLARE_FAULT_ATTR(fail_mmc_request);
-
-#ifdef KERNEL
-/*
- * Internal function. Pass the boot param fail_mmc_request to
- * the setup fault injection attributes routine.
- */
-static int __init setup_fail_mmc_request(char *str)
-{
- return setup_fault_attr(&fail_mmc_request, str);
-}
-__setup("fail_mmc_request=", setup_fail_mmc_request);
-#endif /* KERNEL */
-#endif /* CONFIG_FAIL_MMC_REQUEST */
-
DEFINE_SIMPLE_ATTRIBUTE(mmc_clock_fops, mmc_clock_opt_get, mmc_clock_opt_set,
"%llu\n");
@@ -207,7 +198,9 @@ void mmc_add_host_debugfs(struct mmc_host *host)
goto err_node;
#endif
#ifdef CONFIG_FAIL_MMC_REQUEST
- host->fail_mmc_request = fail_mmc_request;
+ if (fail_request)
+ setup_fault_attr(&fail_default_attr, fail_request);
+ host->fail_mmc_request = fail_default_attr;
if (IS_ERR(fault_create_debugfs_attr("fail_mmc_request",
root,
&host->fail_mmc_request)))
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 3/3] fault-injection: update documenation with the mmc module param
Signed-off-by: Per Forlin --- Documentation/fault-injection/fault-injection.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/fault-injection/fault-injection.txt b/Documentation/fault-injection/fault-injection.txt index 70f924e..ba4be8b 100644 --- a/Documentation/fault-injection/fault-injection.txt +++ b/Documentation/fault-injection/fault-injection.txt @@ -121,7 +121,7 @@ use the boot option: failslab= fail_page_alloc= fail_make_request= - fail_mmc_request=,,, + mmc_core.fail_request=,,, How to add new fault injection capability - -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/3] mmc: rectify boot param option for fault injection
Akinobu Mita reported that the boot option for mmc fault injection is never compiled in due to a fauly "ifdef KERNEL" that is never set. A correct ifdef would be "ifndef MODULE". Akinobu suggested to use a module param instead. This patch set is for 3.2 Per Forlin (3): fault-inject: export setup_fault_attr() mmc: add module param to set fault injection attributes fault-injection: update documenation with the mmc module param Documentation/fault-injection/fault-injection.txt |2 +- drivers/mmc/core/debugfs.c| 29 - lib/fault-inject.c|3 +- 3 files changed, 14 insertions(+), 20 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/3] fault-inject: export setup_fault_attr()
mmc_core module needs to use setup_fault_attr() in order
to set fault injection attributes during module load time.
Signed-off-by: Per Forlin
---
lib/fault-inject.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index 328d433..4f75540 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -14,7 +14,7 @@
* setup_fault_attr() is a helper function for various __setup handlers, so it
* returns 0 on error, because that is what __setup handlers do.
*/
-int __init setup_fault_attr(struct fault_attr *attr, char *str)
+int setup_fault_attr(struct fault_attr *attr, char *str)
{
unsigned long probability;
unsigned long interval;
@@ -36,6 +36,7 @@ int __init setup_fault_attr(struct fault_attr *attr, char
*str)
return 1;
}
+EXPORT_SYMBOL_GPL(setup_fault_attr);
static void fail_dump(struct fault_attr *attr)
{
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9 2/3] mmc: core: add random fault injection
2011/9/14 Per Forlin :
> Hi Akinobu,
>
> On 13 September 2011 16:19, Per Forlin wrote:
>> On 13 September 2011 15:12, Akinobu Mita wrote:
>>> 2011/8/19 Per Forlin :
>>>
+#ifdef KERNEL
+/*
+ * Internal function. Pass the boot param fail_mmc_request to
+ * the setup fault injection attributes routine.
+ */
+static int __init setup_fail_mmc_request(char *str)
+{
+ return setup_fault_attr(&fail_mmc_request, str);
+}
+__setup("fail_mmc_request=", setup_fail_mmc_request);
+#endif /* KERNEL */
>>>
>>> You attempt to enable __setup() only when mmc_core is built into
>>> the kernel. Does it really work? I cannot find any drivers using
>>> "KERNEL" macro.
>>>
>> Your right it doesn't work. I think I change from ifndef MODULE to
>> ifdef KERNEL at one point.
>> It should be "ifndef MODULE"
It's simple and I like this solution.
module_param is more complicated than this. Also the parameter is only
usefull when when mmc_core is built into the kernel (it's useless when
mmc_core is built as a module).
>>> You can use module_param_cb() instead of __setup() without #ifdef KERNEL.
>>> When mmc_core is built into the kernel, you can specify the parameter
>>> with "mmc_core.fail_mmc_request=..."
>>>
> I am considering using module_param() with perm = 0 (not visible in
> sysfs). The purpose of the param is to set fault attributes during
> kerne boot time or module load time. After the kernel boot all can be
> set under debug fs, therefore no need to make the module param
> visible.
>
> What do you think about this? I have not tested it yet.
> --
...
> --
> It's only necessary to call setup_fault_attr() once for all hosts.
> Here it's called one time for each host. I think it's ok since the
> routine is small and used for debugging purposes.
> I could use a static bool to indicate whether setup_fault_attr() has
> already been issued.
> + if (fail_mmc_request && !setup_fault_attr_done)
module_param_cb() doesn't work as you expected? (Although I suggested
to use #ifdef MODULE instead of #ifdef KERNEL, I'm just asking out of
curiosity)
static int fail_mmc_request_param_set(const char *val,
const struct kernel_param *kp)
{
setup_fault_attr(&fail_mmc_request, val);
return 0;
}
static const struct kernel_param_ops fail_mmc_request_param_ops = {
.set = fail_mmc_request_param_set
};
module_param_cb(fail_mmc_request, &fail_mmc_request_param_ops,
&fail_mmc_request, 0);
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux
2011/9/13 Linus Walleij :
> On Fri, Sep 2, 2011 at 6:04 PM, Stephen Warren wrote:
>> Linus Walleij wrote at Friday, September 02, 2011 2:12 AM:
>>> On Thu, Sep 1, 2011 at 11:33 PM, Stephen Warren wrote:
>>>
>>> >> +static const struct u300_pmx_func u300_pmx_functions[] = {
>>> >> + {
>>> >> + .name = "power",
>>> >> + .groups = { POWERGRP_INDEX },
>>> >> + /* Mask is N/A */
>>> >> + },
>>> >
>>> > Hmmm. That's a lot of _INDEX defines that'd need to be set up, at least
>>> > to fully represent a chip like Tegra. Can the pinmux core be modified
>>> > such that the group list is an array of names (char*) rather than the
>>> > actual numeric IDs of the groups? Still, perhaps we could use the enum
>>> > we already have for this, so perhaps it isn't a big deal...
>>>
>>> Well I could think about a lot of ways to do this, but it's basically up
>>> to the driver, the U300 is just some simple example of what you can
>>> do, it's just trying to satisfy the API.
>>>
>>> Maybe as part of writing the nVidia driver you find a clever
>>> mechanism for doing this, if it's looking generally useful at that
>>> point then let's move it to the core I'd say.
>>
>> The reason I asked about the pinmux core handling this is because the
>> driver op get_function_groups:
>>
>> + int (*get_function_groups) (struct pinctrl_dev *pctldev,
>> + unsigned selector,
>> + unsigned ** const groups,
>> + unsigned * const num_groups);
>>
>> returns an array of integer indexes. I think the only way to get rid of
>> the index definitions in the drivers is to allow get_function_groups to
>> return an array of strings instead.
>
> OK good idea, I reworked this interface to get an array of strings
> instead, I've been told several times to use strings rather than numbers
> when possible, so I think this is the right thing to do.
>
> Check it out in v7!
well. we'll rebase prima2 pinmux on v7.
>
> Yours,
> Linus Walleij
>
-barry
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
Hello Rob.
Sorry for being late. here was a national holiday.
> -Original Message-
> From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
> Clark
> Sent: Thursday, September 08, 2011 3:44 AM
> To: Inki Dae
> Cc: linaro-dev@lists.linaro.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH] RFC: omapdrm DRM/KMS driver for TI OMAP platforms
>
> On Wed, Sep 7, 2011 at 1:00 AM, Inki Dae wrote:
> > Hello, Rob.
> >
> [snip]
> >> >> +static void page_flip_cb(void *arg)
> >> >> +{
> >> >> + struct drm_crtc *crtc = arg;
> >> >> + struct drm_device *dev = crtc->dev;
> >> >> + struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
> >> >> + struct drm_pending_vblank_event *event = omap_crtc->event;
> >> >> + struct timeval now;
> >> >> + unsigned long flags;
> >> >> +
> >> >> + WARN_ON(!event);
> >> >> +
> >> >> + omap_crtc->event = NULL;
> >> >> +
> >> >> + update_scanout(crtc);
> >> >> + commit(crtc);
> >> >> +
> >> >> + /* wakeup userspace */
> >> >> + // TODO: this should happen *after* flip.. somehow..
> >> >> + if (event) {
> >> >> + spin_lock_irqsave(&dev->event_lock, flags);
> >> >> + event->event.sequence =
> >> >> + drm_vblank_count_and_time(dev,
> >> > omap_crtc->id,
> >> >> &now);
> >> >> + event->event.tv_sec = now.tv_sec;
> >> >> + event->event.tv_usec = now.tv_usec;
> >> >> + list_add_tail(&event->base.link,
> >> >> + &event->base.file_priv->event_list);
> >> >> +
> > wake_up_interruptible(&event->base.file_priv->event_wait);
> >> >> + spin_unlock_irqrestore(&dev->event_lock, flags);
> >> >> + }
> >> >
> >> > How about moving codes above into interrupt handler for vblank?
> >> > maybe there
> >>
> >> I should mention a couple of things:
> >>
> >> 1) drm vblank stuff isn't really used currently.. it is actually DSS2
> >> layer that is registering for the display related interrupt(s). I'm
> >> not really sure how to handle this best. I suppose the DRM driver
> >> could *also* register for these interrupts, but that seems a bit odd..
> >>
> >
> > DRM Framework supports only one interrupt handler. this issue should be
> > resolved. and currently I made our driver to use its own request_irq,
> not
> > DRM Framework side. we only sets drm_device->irq_enabled to 1 and
> interrupt
> > handler is registered at display controller or hdmi driver respectively.
> but
> > I'm not sure that this way is best so I will look over more. Anyway
> current
> > drm framework should be fixed to be considered with multiple irq.
>
> Or perhaps even callbacks (some other driver handling the irq's directly)?
>
Yes.
> >> Also, I guess it is also worth mentioning.. when it comes to vblank,
> >> there are two fundamentally different sorts of displays we deal with.
> >> Something like DVI/HDMI/etc which need constant refreshing. In these
> >> cases we constantly scan-out the buffer until the next page
> >> flip+vsync. And smart panels, where they get scanned out once and
> >> then DSS is no longer reading the scanout buffer until we manually
> >> trigger an update.
> >>
> >
> > Is the Smart panel CPU interface based lcd panel that has its own
> > framebuffer internally.?
>
> yes
>
CPU Interface based lcd panel needs manual updating once all contents of
internal framebuffer are transferred to panel. thus, the Smart Panel(cpu
interface based lcd panel) has advantage of power consumption with
user-requested update. this means application should trigger display
controller to be transferred to lcd panel at framedone signal of lcd panel
because only the application is aware of this moment. this way would be
getting confused, especially on general os, such as linux system, based
platform so in case of using Smart Panel, I think we should make the panel
driver to be worked like RGB interface.
- framedone interrupt handler of the panel should be placed in the driver.
- at booting time, display controller driver triggers just one time
- the panel driver triggers every time framedone interrupt handler is
called.
and the order above would be repeated like RGB interface. thus I think we
could deal with the Smart Panel like RGB way.
> [snip]
> >>
> >> The main reason for the page-flip cb is actually not vsync
> >> synchronization, but rather synchronizing with other hw blocks that
> >> might be rendering to the buffer.. the page flip can be submitted
> >> from userspace while some other hw block (3d, 2d, etc) is still
> >> DMA'ing to the buffer. The sync-obj is intended to give a way to
> >> defer the (in this case) page flip until other hw blocks are done
> >> writing to the buffer.
> >
> > I thought page-flip is used to change buffer register value of display
> > controller into another one like the Pan Display feature of linux
> > framebuffer. actually page flip interface of libdrm library,
> > page_flip_handler, is
install alsa ucm configurations
Hi, I initiate an install script for ucm configurations. The basic idea is -- 1. Decide the destination directory (if not specified by arguments, detect it) 2. Decide target sound card (must be specified by argument, and only the target configurations will be installed) 3. After copying ucm configurations to destinations, initiate the alsa mixer to ucm default values The script is install.sh at http://git.linaro.org/gitweb?p=people/weifeng/alsa-ucm-conf.git. Please check and if there're more requirements for linaro 1109 release, please tell me. -- Wei.Feng (irc wei_feng) Linaro Multimedia Team Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
Hi Siarhei, Interesting feature, and it's not samsung soc issue, so add the arm mailing list. It checked and the see the read performance improvement from 868MiB/s to 981MiB/s with lmbench. It's helpful to test other SoC., e.g., OMAP4, STE and so on. BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit and should be zero (SBZ). Thank you, Kyungmin Park On Tue, Sep 13, 2011 at 3:07 PM, Siarhei Siamashka wrote: > Setting "Double linefill enable" bit improves memcpy performance > from ~750 MB/s to ~1150 MB/s when working with large buffers and > also the performance of just anything which may need good memory > bandwidth (for example, software rendered graphics). > > Additionally setting "Double linefill on WRAP read disable" bit > compensates most of the random access latency increase. > > Signed-off-by: Siarhei Siamashka > --- > arch/arm/mach-exynos4/cpu.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c > index ba503c3..1afd25f 100644 > --- a/arch/arm/mach-exynos4/cpu.c > +++ b/arch/arm/mach-exynos4/cpu.c > @@ -238,7 +238,7 @@ static int __init exynos4_l2x0_cache_init(void) > __raw_writel(0x110, S5P_VA_L2CC + L2X0_DATA_LATENCY_CTRL); > > /* L2X0 Prefetch Control */ > - __raw_writel(0x3007, S5P_VA_L2CC + L2X0_PREFETCH_CTRL); > + __raw_writel(0x7807, S5P_VA_L2CC + L2X0_PREFETCH_CTRL); > > /* L2X0 Power Control */ > __raw_writel(L2X0_DYNAMIC_CLK_GATING_EN | L2X0_STNDBY_MODE_EN, > -- > 1.7.3.4 > > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
On Wednesday 14 September 2011 11:38 AM, Kyungmin Park wrote: Hi Siarhei, Interesting feature, and it's not samsung soc issue, so add the arm mailing list. It checked and the see the read performance improvement from 868MiB/s to 981MiB/s with lmbench. It's helpful to test other SoC., e.g., OMAP4, STE and so on. BTW, why do you set the 27-bit? In my PL310 Spec., it's reserved bit and should be zero (SBZ). That's because not all PL310 versions double line fill. Regards santosh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9 2/3] mmc: core: add random fault injection
On 14 September 2011 01:37, Akinobu Mita wrote:
> 2011/9/14 Per Forlin :
>> Hi Akinobu,
>>
>> On 13 September 2011 16:19, Per Forlin wrote:
>>> On 13 September 2011 15:12, Akinobu Mita wrote:
2011/8/19 Per Forlin :
> +#ifdef KERNEL
> +/*
> + * Internal function. Pass the boot param fail_mmc_request to
> + * the setup fault injection attributes routine.
> + */
> +static int __init setup_fail_mmc_request(char *str)
> +{
> + return setup_fault_attr(&fail_mmc_request, str);
> +}
> +__setup("fail_mmc_request=", setup_fail_mmc_request);
> +#endif /* KERNEL */
You attempt to enable __setup() only when mmc_core is built into
the kernel. Does it really work? I cannot find any drivers using
"KERNEL" macro.
>>> Your right it doesn't work. I think I change from ifndef MODULE to
>>> ifdef KERNEL at one point.
>>> It should be "ifndef MODULE"
>
> It's simple and I like this solution.
>
It's simple and the patch would be just two lines.
The reason for changing my mind is that it may be useful to be able to
pass the fault injection attributes even when mmc_core is a module.
> module_param is more complicated than this. Also the parameter is only
> usefull when when mmc_core is built into the kernel (it's useless when
> mmc_core is built as a module).
>
If you want to enable fault injection for the mmc_core module at load
time (during mmc initialisation) the param must be used.
modprobe mmc_core fail_request=1,1,1,1
As soon as the module is loaded there is no need for the module param anymore.
You can use module_param_cb() instead of __setup() without #ifdef KERNEL.
When mmc_core is built into the kernel, you can specify the parameter
with "mmc_core.fail_mmc_request=..."
>> I am considering using module_param() with perm = 0 (not visible in
>> sysfs). The purpose of the param is to set fault attributes during
>> kerne boot time or module load time. After the kernel boot all can be
>> set under debug fs, therefore no need to make the module param
>> visible.
>>
>> What do you think about this? I have not tested it yet.
>> --
>
> ...
>
>> --
>> It's only necessary to call setup_fault_attr() once for all hosts.
>> Here it's called one time for each host. I think it's ok since the
>> routine is small and used for debugging purposes.
>> I could use a static bool to indicate whether setup_fault_attr() has
>> already been issued.
>> + if (fail_mmc_request && !setup_fault_attr_done)
>
> module_param_cb() doesn't work as you expected?
I made a silly mistake thinking the set() hook would only be issued if
setting the param via sysfs. I turned out that I just mistyped the
boot-param name, sorry.
I now have a working test with module_param_cb() implemented.
Thanks,
Per
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
