Hi,
On Fri, Jun 08, 2012 at 01:20:13, CF Adad wrote:
Thanks for your thoughts! I may try fiddling a bit just to see if that helps.
5 series of patches for gpmc modifications [1-5] has been posted,
In case it helps in resolving your issue, please let me know.
You will have to use the new
Hi Tony,
On Tue, May 22, 2012 at 22:12:15, Tony Lindgren wrote:
for these cases. Otherwise we'll be breaking old boards with smsc911x
where the timings for the FPGA controlling smsc911x are unknown.
Were you actually referring to sdp boards that work with smc91x driver
using 91c96 ?
Regards
Hi Jon,
On Tue, Jun 12, 2012 at 14:10:08, Mohammed, Afzal wrote:
+ l |= conf GPMC_CONFIG1_DEVICETYPE_NAND;
+ l |= conf GPMC_CONFIG1_DEVICESIZE_16;
I can see that it works to use the above definitions as masks because of
the possible values that can be programmed into these fields
Hi Jon,
On Tue, Jun 12, 2012 at 23:06:53, Hunter, Jon wrote:
Should you at least warn, if you are going to over-write a value?
Yes, that would be better except for too much logging, if Tony
prefers that way I will add.
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe
Hi Jon,
On Tue, Jun 12, 2012 at 23:00:48, Hunter, Jon wrote:
On 06/12/2012 01:16 AM, Mohammed, Afzal wrote:
With the existing code, set_async was done as part of set_sync, hence
requiring GPMC to be configured twice after driver takes control, with
your suggestion too, GPMC would have
Hi Jon,
On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote:
On 06/12/2012 01:53 AM, Mohammed, Afzal wrote:
On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote:
My preference would be to store gpmc_l3_clk in the pdata and pass to
probe via the pdata. The aim would be to remove the global
Hi Jon,
On Tue, Jun 12, 2012 at 23:16:50, Hunter, Jon wrote:
Ok, I see that this is necessary until all boards are migrated. However,
please label with a FIXME to make it clear that this is to be removed.
Ok, I will update this.
Regards
Afzal
--
To unsubscribe from this list: send the line
Hi Jon,
On Tue, Jun 12, 2012 at 23:32:05, Hunter, Jon wrote:
Well looking at the function it seems that you either return an error
code or 1. So if you are never going to return anything other than 1 on
success it may as well be 0.
Irq memory resource creation functions returns number of
Hi Jon,
On Tue, Jun 12, 2012 at 23:36:17, Hunter, Jon wrote:
Well it is unclear what the code flow is for using this helper as this
change simply adds the helper. If someone other function is writing to
the CONFIG1 register before this function, then you may wish to
highlight the programming
Hi Jon,
On Tue, Jun 12, 2012 at 23:39:32, Hunter, Jon wrote:
On 06/12/2012 07:58 AM, Mohammed, Afzal wrote:
Thinking again over it, I am feeling above is sufficient, reason same as
said earlier, to keep code simple currently this is sufficient to
handle GPMC bit patterns for IPs
Hi Jon,
On Mon, Jun 11, 2012 at 21:13:45, Hunter, Jon wrote:
Which boards have been tested with this change?
Beagle board
Reviewed-by: Jon Hunter jon-hun...@ti.com
Thanks
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Hi ,
On Wed, Jun 06, 2012 at 13:21:23, CF Adad wrote:
Thanks again. I'm really starting to think the GPMC almost has to be
contributing.
Does adding cycle2cycle delay / bus turnaround prevent the issue ?,
SMSC datasheet mentions about special restrictions on back to back read
and
Hi,
On Mon, Jun 04, 2012 at 12:15:01, Mohammed, Afzal wrote:
Hi,
This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to happen shortly would happen smoothly
by not creating much disturbance outside of arch/arm/*omap*/
This series,
1. provides
Hi Tony,
On Fri, May 25, 2012 at 12:56:59, Tony Lindgren wrote:
* Paul Walmsley p...@pwsan.com [120523 17:55]:
On Tue, 22 May 2012, Tony Lindgren wrote:
Unfortunately for many of the older boards these values will probably
remain unknown.
So the better approach here is to just
Hi Artem,
On Tue, May 22, 2012 at 11:44:43, Artem Bityutskiy wrote:
You merge the 2 trees and work on top of that? Or you wait for 3.5-r1
when everything is merged and work on top of that?
I will merge 2 trees do
Tony, are you ok with that ?
Regards
Afzal
Hi Paul,
On Tue, May 22, 2012 at 12:17:30, Paul Walmsley wrote:
Hi Afzal
On Thu, 10 May 2012, Mohammed, Afzal wrote:
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
(attribution lost)
Hmm, second time, normally I try to delete as much as possible contents from
the original mail
Hi Ivan,
On Sat, May 19, 2012 at 18:20:18, Ivan Djelic wrote:
Hi Afzal,
I tried to take your series of patches, but I had issues with the
first [1] (I did not try the others): it depends on the following patch,
which is not in the l2-mtd-2.6 tree:
Hi Santosh,
On Fri, May 18, 2012 at 12:33:16, Shilimkar, Santosh wrote:
+ Afzal who has been doing quite a bit of GMPC work recently.
On Fri, May 18, 2012 at 10:13 AM, Ming Lei ming@canonical.com wrote:
The IRQ52 on OMAP2+ is not a shared interrupt line. If IRQF_SHARED
is passed to
Hi Maxim,
On Fri, May 18, 2012 at 13:23:53, Maxim Podbereznyy wrote:
Hey guys!
Who knows how to initialize and use tps65910 driver in linux with
am3517? I designed a board using the Craneboard schematic as a
reference. Mistral provides the kernel 2.6.32 and it works fine. Now
I'm porting
Hi Santosh,
On Fri, May 18, 2012 at 15:43:31, Shilimkar, Santosh wrote:
On the side note, looks like GMPC too needs to be converted
to sparse IRQ since it seems to be creating a dummy irqchip
and dispatching secondary handlers based on chip selects.
GPMC dummy chip is being modified to so
Hi Thomas,
On Tue, May 15, 2012 at 12:00:32, Thomas Weber wrote:
I need a help.
Can someone familiar with boards - devkit8000, omap3touchbook, overo boards,
let me know GPMC CS on which NAND is connected.
On Devkit8000 the NAND is connected to CS0.
Thanks for the information
I
Hi Tony,
On Tue, May 15, 2012 at 20:08:34, Mohammed, Afzal wrote:
Modify interrupt handling such that interrupts can be handled by GPMC
client drivers using standard interrupt APIs rather than requiring
the drivers to have knowledge about GPMC interrupt handling. Currently
only NAND related
Hi All,
On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote:
Some boards depend on bootloader to update chip select value for NAND.
It is felt that Kernel should not depend on bootloader to get CS, as
for a particular board CS is hardwired and is fixed, hence this can
directly
Hi Tony,
On Sat, May 12, 2012 at 01:30:49, Tony Lindgren wrote:
Let's try to get merged these into l-o master around -rc2 so we can
have them tested properly for a few weeks before v3.6 merge window.
Sure, this will be my goal
Regards
Afzal
--
To unsubscribe from this list: send the line
Hi Ivan,
On Thu, May 10, 2012 at 23:15:27, Ivan Djelic wrote:
So, when Afzal's patches are pushed, I'll submit a new, single MTD patch.
But this is not going to happen this merge window as I understood, may
be not even the next one. We need to make UBIFS happy sooner than that,
I
Hi Paul,
On Thu, May 10, 2012 at 11:33:44, Mohammed, Afzal wrote:
Hi Paul,
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break
Hi Paul,
On Tue, May 08, 2012 at 21:02:33, Paul Walmsley wrote:
Major reason was that there are some boards that rely on bootloader
settings, eg. kernel does not do any setting for smsc911x. I did not
want to break those, at least it causes problem with omap3evm, see below
But this is
Hi Tony,
On Wed, May 09, 2012 at 03:06:26, Tony Lindgren wrote:
To resolve this and as per your earlier question on whether old along
with new interface can be made to work parallely, here is suggestion
from my end to deal with it.
I think this is the only way to keep this all building
Hi Ivan,
On Wed, May 09, 2012 at 21:01:42, Tony Lindgren wrote:
Note that I could prepare a new MTD patch with BCH ecc code included,
allowing to drop the GPMC BCH ecc api.
OK, let's do that then. I'll drop this patch and you can coordinate
your patch with Afzal.
Now that some review
Hi Jon,
On Tue, May 08, 2012 at 20:38:24, Hunter, Jon wrote:
Different ways of doing things, this looks cleaner to me as already it is
checked, and time of execution in both cases would not differ much.
Sure. However, I think that this could be simplified so that it is
easier to read. At
Hi Jon,
On Tue, May 08, 2012 at 20:43:19, Hunter, Jon wrote:
In fact if you migrate to runtime pm then we should not have the clk_get
in the gpmc_init any more.
Even if converted to RPM, to get clk rate, clk_get has to be done
somewhere, right ?
Yes exactly. However, you could now
Hi Jon,
On Mon, May 07, 2012 at 21:32:58, Hunter, Jon wrote:
+ /* no waitpin */
+ case 0:
+ break;
+ default:
+ dev_err(gpmc-dev, multiple waitpins selected on CS:%u\n, cs);
+ return -EINVAL;
+ break;
+ }
Why not combined case 0 and default?
Hi Jon,
On Mon, May 07, 2012 at 21:42:35, Hunter, Jon wrote:
Clk_prd is a platform data passed to the driver, so platform code
updates it, where else can it be done ?
The point is that you can pass what ever you like. You do not need to
pass the frequency you can pass the clock handle
Hi Jon,
On Mon, May 07, 2012 at 21:53:34, Hunter, Jon wrote:
Write protect is a pin and there is only one. Like the waitpins and CS
signals this needs to be associated with a device. It would make sense
that this is associated with the cs data.
As far as platform are concerned, it is
Hi Tony,
On Tue, May 01, 2012 at 17:49:03, Mohammed, Afzal wrote:
GPMC driver conversion patch series. Some peripherals has GPMC helper
functions, these has been modified to cater to the needs of GPMC
driver. All the boards using GPMC has been adapted to use the new
GPMC driver.
GPMC HWMOD
Hi Paul,
On Mon, May 07, 2012 at 16:42:16, Mohammed, Afzal wrote:
+static struct omap_hwmod omap3xxx_gpmc_hwmod = {
+ .name = gpmc,
+ .class = omap3xxx_gpmc_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap3xxx_gpmc_irqs,
+ .main_clk
Hi Jon,
On Fri, May 04, 2012 at 21:50:16, Hunter, Jon wrote:
As mentioned in the cover letter,
Additional features that currently boards in mainline does not make
use of like, waitpin interrupt handling, changes to leverage revision
6 IP differences has not been incorporated.
Hi Jon,
On Fri, May 04, 2012 at 21:57:10, Hunter, Jon wrote:
- gpmc_write_reg(GPMC_SYSCONFIG, l);
- gpmc_mem_init();
+ switch (conf GPMC_WAITPIN_MASK) {
+ case GPMC_WAITPIN_0:
+ idx = GPMC_WAITPIN_IDX0;
+ break;
+ case GPMC_WAITPIN_1:
+
Hi Jon,
On Fri, May 04, 2012 at 22:00:21, Hunter, Jon wrote:
+
+ pdata-clk_prd = gpmc_get_fclk_period();
Does this need to be done here? May be this should be done in the probe
function. You could store the handle to the main clk in the pdata.
This is done so that migration of gpmc
Hi Paul,
On Sun, May 06, 2012 at 07:34:07, Paul Walmsley wrote:
Did you notice the warning that this patch generates on boot?
omap_hwmod: gpmc: cannot be enabled for reset (3)
The HWMOD_NO_IDLEST hwmod flag is needed, since there is no GPMC IDLEST
bit.
Yes, putting that flag makes
Hi Jon,
On Tue, May 01, 2012 at 23:23:00, Hunter, Jon wrote:
Hi Afzal,
Looks good! Some minor comments ...
Thanks
+#defineGPMC_WAITPIN_IDX0 0x0
+#defineGPMC_WAITPIN_IDX1 0x1
+#defineGPMC_WAITPIN_IDX2 0x2
Hi Jon,
On Wed, May 02, 2012 at 02:11:48, Hunter, Jon wrote:
+
+ pdata-clk_prd = gpmc_get_fclk_period();
Does this need to be done here? May be this should be done in the probe
function. You could store the handle to the main clk in the pdata.
This is done so that migration of gpmc
Hi Jon,
On Wed, May 02, 2012 at 02:46:02, Hunter, Jon wrote:
Some boards depend on bootloader to update chip select value for NAND.
It is felt that Kernel should not depend on bootloader to get CS, as
for a particular board CS is hardwired and is fixed, hence this can
directly be updated
Hi Sergei,
On Tue, May 01, 2012 at 22:19:37, Sergei Shtylyov wrote:
+
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
You can use IS_ENABLED(CONFIG_MTD_ONENAND_OMAP2) instead these two.
Thanks for educating me.
Regards
Afzal
--
To
Hi Kevin,
On Tue, May 01, 2012 at 02:10:28, Hilman, Kevin wrote:
Afzal, care to give this one a test as well? It should have the same
result but is a more targetted fix. With and ack from Tero and a
Tested-by from you, I'll post this to the list and and queue it up for
v3.5.
Over what
Hi Kevin,
On Tue, May 01, 2012 at 19:38:00, Hilman, Kevin wrote:
Afzal, care to give this one a test as well? It should have the same
result but is a more targetted fix. With and ack from Tero and a
Tested-by from you, I'll post this to the list and and queue it up for
v3.5.
With an
Hi Kevin,
On Sat, Apr 28, 2012 at 04:45:21, Hilman, Kevin wrote:
Afzal, care to test the patch below to see if it fixes your boot problem
on OMAP3EVM with the IO chain series?
Your patch fixes the boot problem
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe
Hi Tony,
On Wed, Apr 25, 2012 at 22:14:25, Tony Lindgren wrote:
Once driver is acceptable, platform code for other peripherals
connected via GPMC would be adapted to make use of GPMC driver. And
then the board modifications. But before that HWMOD entry has to be
populated for respective
Hi Tony,
On Wed, Apr 25, 2012 at 22:17:26, Tony Lindgren wrote:
Obviously we can't merge any of this if until all the board-*.c files
are changed and tested.
Can you maybe still keep the old interfaces in addition to the new ones
so we can do the conversion one board-*.c file at a time
Hi Tero,
On Mon, Apr 23, 2012 at 17:29:48, Kristo, Tero wrote:
Okay thats good (although I wonder why the attachment got corrupted.)
Did you check if the device suspends / resumes properly also? Can you
check what do you have in the /proc/interrupts for the hwmod_io
interrupt just after boot
Hi Tero,
With this branch you meant,
HEAD @ 297624c ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle,
right ? (the one Paul suggested to try)
Regards
Afzal
On Mon, Apr 23, 2012 at 14:54:04, Kristo, Tero wrote:
On Fri, 2012-04-06 at 07:52 +, Mohammed, Afzal wrote:
Hi Paul
Hi Tero,
On Mon, Apr 23, 2012 at 15:43:22, Kristo, Tero wrote:
can you try the attached patch with this branch and omap3evm board? I
don't have the board myself so I can't test it myself (I tested this
with omap3beagle and it works with that one.)
With your patch, OMAP3EVM boots
Hi Aneesh,
On Fri, Apr 13, 2012 at 01:28:55, V, Aneesh wrote:
Thanks. I will wait for your review then. Once I have your comments
I will re-work and submit in the new directory structure proposed.
Do you have a plan on submitting EMIF driver in the new proposed
(drivers/memory) directory. Or
Hi Santosh,
On Mon, Apr 23, 2012 at 16:34:46, Shilimkar, Santosh wrote:
Please go ahead in creating directory.
Thanks for the quick reply.
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo
+ 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:
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
Hi Greg,
On Thu, Apr 12, 2012 at 18:40:45, Greg KH wrote:
On Thu, Apr 12, 2012 at 12:17:49PM +0530, Santosh Shilimkar wrote:
I was hoping that we will have some thing like drivers/memory/*
but since it doesn't exist, we used drivers/misc.
Why not create it? I have no objection to that,
Hi Greg,
On Thu, Apr 12, 2012 at 19:40:50, Greg KH wrote:
There is another memory controller used in a few TI SoCs,
namely GPMC [1], do you prefer having it too there.
Sure, why not?
Thanks a lot, we were struggling to find a suitable location for the driver.
Regards
Afzal
--
To
Hi Jon,
On Tue, Apr 10, 2012 at 01:20:37, Hunter, Jon wrote:
Because num_irq (or available irqs for fictitious irq chip) is platform
specific.
Ok, so OMAP_GPMC_NR_IRQS is defined and will not vary from device to
device, so why pass this? Why not use it directly?
Because
Hi Jon,
On Wed, Apr 11, 2012 at 00:53:14, Hunter, Jon wrote:
I agree with your argument but I was thinking today only OMAP uses the
GPMC so we could not worry about this. Ok, leave as-is, but can we
modify the code as follows as the else if is not really needed...
if (gpmc-num_irq
Hi Jon,
On Wed, Apr 11, 2012 at 00:54:58, Hunter, Jon wrote:
+#defineGPMC_NAND_CONFIG_NUM4
Where does 4 come from?
It depends on the use case, for NAND, with the way it was being
configured (or number of times gpmc_cs_configure was being called)
4 are needed.
Regards
Afzal
--
To
Hi Jon,
On Fri, Apr 06, 2012 at 01:51:41, Hunter, Jon wrote:
+struct gpmc_irq{
+ unsignedirq;
+ u32 regval;
Are you using regval to indicate the bit-mask? If so, maybe call it
bitmask instead.
Yes, bitmask would be better.
+
Hi Paul,
On Fri, Apr 06, 2012 at 12:43:06, Paul Walmsley wrote:
Perhaps you might be willing to add some debugging to omap_mux_late_init()
to find out what part of that function is causing it to hang?
It is getting hung as interrupt handler omap_hwmod_mux_handle_irq
is being repeatedly
Hi Paul,
On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote:
Could you try booting with initcall_debug and posting the boot log?
Logs as follows,
Regards
Afzal
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version
Hi Govindraj,
On Thu, Apr 05, 2012 at 15:53:25, R, Govindraj wrote:
Can you try this patch [1], Just to confirm its serial mux issue
however still the patch is not aligned on how to fix it.
With that patch too, Kernel does not boot.
Regards
Afzal
--
To unsubscribe from this list: send the
Hi Paul,
On Thu, Apr 05, 2012 at 15:37:42, Paul Walmsley wrote:
I just booted the 'io_chain_devel_3.5' branch from
git://git.pwsan.com/linux-2.6 on a 35xx ES3.0 BeagleBoard with no
problems. Could you please try booting this branch on your OMAP3EVM?
I am unable to fetch using git protocol,
Hi Tony,
On Thu, Apr 05, 2012 at 22:46:53, Tony Lindgren wrote:
What happens if you disable CONFIG_OMAP_MUX?
Then it boots properly.
Regards
Afzal
--
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
Hi Paul,
On Fri, Apr 06, 2012 at 01:22:20, Paul Walmsley wrote:
http://git.kernel.org/?p=linux/kernel/git/pjw/omap-devel.git;a=summary
If you open it in your web browser, it shows http and https URLs for the
tree that you should be able to pull from. You'll want the
io_chain_devel_3.5
Hi,
On Wed, Apr 04, 2012 at 11:06:39, Mohammed, Afzal wrote:
OMAP3EVM is not booting on l-o master, with default configuration, HEAD
@33fc21e Linux-omap rebuilt: Updated to v3.4-rc1, merged in most of pending
branches.
Reverting merge commit
58adb29 Merge branch 'io_chain_devel_3.4' of git
Hi,
OMAP3EVM is not booting on l-o master, with default configuration, HEAD
@33fc21e Linux-omap rebuilt: Updated to v3.4-rc1, merged in most of pending
branches.
It was booting on l-o master two weeks old with same setup.
Any clues on resolving this issue ?
Regards
Afzal
Logs as follows,
Hi Jon,
On Tue, Mar 27, 2012 at 21:01:56, Hunter, Jon wrote:
These are for the peripheral resources not in control of GPMC, like
gpio irq. These are copied in gpmc_create_child.
Right, I see they are copied during gpmc_create_child. However, I don't
see where they are initialised before
Hi Benoit,
On Fri, Mar 23, 2012 at 21:09:21, Cousson, Benoit wrote:
But EMIF does not have anything to do in MFD either :-)
What was the feedback for this series?
We discussed that at Linaro connect, but it looks like MFD is becoming
the place for miscellaneous drivers that we do not
Hi Santosh,
On Fri, Mar 23, 2012 at 16:05:47, Shilimkar, Santosh wrote:
Much needed series. Thanks Afzal for doing it.
Probably going through this first version, your thanks would have evaporated;
else if (thanks 0)
redirected to Vaibhav Hiremath Sekhar Nori.
Regards
Afzal
--
To
Hi Balbi,
On Fri, Mar 23, 2012 at 21:59:00, Balbi, Felipe wrote:
yeah, I was thinking about drivers/ocd (off-chip devices) or
drivers/mmio... and that should be flexible enough to hold gpmc, lli and
c2c (from OMAP's perspective).
Ok, I will check feasibility of having GPMC driver at those
Hi Jon,
On Sat, Mar 24, 2012 at 04:51:13, Hunter, Jon wrote:
+struct gpmc_child {
+ char*name;
+ int id;
+ struct resource *res;
+ unsignednum_res;
+ struct resource gpmc_res[GPMC_CS_NUM];
Does this
Hi Jon,
On Mon, Mar 26, 2012 at 23:12:26, Hunter, Jon wrote:
Also, I don't see where the gpmc_child-res and gpmc_child-num_res are
actually used. Are these needed?
These are for the peripheral resources not in control of GPMC, like
gpio irq. These are copied in gpmc_create_child.
Hi Jon,
On Mon, Mar 26, 2012 at 23:21:50, Hunter, Jon wrote:
I see this is marked as a temp patch, but this is actually needed to
register the device. Actually, we would need to do this for all boards,
right?
Yes, as NAND support on OMAP3EVM was not in mainline, made it TMP.
Once GPMC
Hi Jon,
On Tue, Mar 27, 2012 at 10:49:32, Mohammed, Afzal wrote:
Hi Jon,
On Mon, Mar 26, 2012 at 23:21:50, Hunter, Jon wrote:
I see this is marked as a temp patch, but this is actually needed to
register the device. Actually, we would need to do this for all boards,
right?
Yes
Hi Benoit,
On Fri, Mar 23, 2012 at 15:07:30, Cousson, Benoit wrote:
Final destination aimed for this driver is MFD.
Why? Are you sure this is appropriate? This is not really a
multifunction device but rather a bus device that can manage multiple
kind of devices.
Agree, this not an MFD,
Hi Kevin,
On Fri, Mar 02, 2012 at 03:37:51, Hilman, Kevin wrote:
Thanks, will queue this with the CPUfreq changes for MPU DVFS.
Actually, not quite yet...
After some testing with the SMPS regulators, this won't quite work with
the current SMPS regulators. Does this actually work with
Hi Kevin,
On Thu, Feb 23, 2012 at 00:12:06, Hilman, Kevin wrote:
And in my patch plus - minus was not used as regulator framework will
try to set voltage for the least voltage which sometimes corresponds
to exact OPP required value.
sometimes?
I was not clear in my previous statement,
Hi Kevin,
On Thu, Feb 23, 2012 at 10:58:57, Mohammed, Afzal wrote:
Using your example above, what if the closest value was 1.259V?
Wouldn't you then need +/- range?
In that case, it will set to next step after 1.259V.
If +/- is used, it may happen that SoC will work for a particular
Hi Kevin,
On Wed, Feb 22, 2012 at 05:36:12, Hilman, Kevin wrote:
In this case, volt comes from the OPP table, and was requested using a
rounding call into the OPP table, so the resolution problem is handled
there. If 'volt' cannot be set by the regulator, then the OPP tables
are also broken.
Hi Kevin,
On Fri, Feb 17, 2012 at 00:50:43, Hilman, Kevin wrote:
+ /* scaling up? scale voltage before frequency */
+ if (mpu_reg (freqs.new freqs.old))
+ regulator_set_voltage(mpu_reg, volt, volt);
Probably voltage ranges has to be specified, otherwise
if I understand
Hi Benoit,
HWMOD entries currently does contain GPMC, is it due to the reason that
GPMC is not yet adapted to omap_device / omap_hwmod or is there any
other reason for not having it in HWMOD (as GPMC not yet a driver?)
Yes, that's the reason.
Nobody had the time to update that driver
Hi Tony,
On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote:
The plan is to deprecate the existing arch/arm/*omap*/*mux* code,
and cut it down to minimum. And then add DT only mux support that should
work for at least omap2+. That should work for am335x too.
There's currently some
Hi Tony,
I am working on implementing pincontrol driver for AM335X SoC (OMAP34XX family).
Is there any specific plan you have in mind w.r.t incorporating
pincontrol driver for OMAP family of SoC's. There was an initial patch
for OMAP4 pin control driver, but it seems you were in favour of a
DT
Hi Kevin,
On Thu, Dec 01, 2011 at 20:40:03, Hilman, Kevin wrote:
Hiremath, Vaibhav hvaib...@ti.com writes:
:
We can detect the board using on-board EEPROM, so same mach-id
should work for both EVM and Beagle.
And also going forward with device tree approach we may
not need different
Hi Liam,
On Tue, Nov 08, 2011 at 21:26:39, Mark Brown wrote:
On Tue, Nov 08, 2011 at 06:54:10PM +0530, Afzal Mohammed wrote:
Count of selector voltage is required for regulator_set_voltage
to work via set_voltage_sel. VDD1/2 currently have it as zero,
so regulator_set_voltage won't work
Hi Kyle,
On Thu, Nov 03, 2011 at 22:38:01, Kyle Manna wrote:
+ ret = mfd_add_devices(tps65910-dev, -1, tps65910s,
+ ARRAY_SIZE(tps65910s), NULL, 0);
+ if (ret 0)
+ goto err2;
Isn't goto err sufficient
Regards
Afzal
--
To unsubscribe from this list:
Hi Brown,
On Fri, Nov 04, 2011 at 19:34:22, Mark Brown wrote:
On Fri, Nov 04, 2011 at 06:18:48PM +0530, Afzal Mohammed wrote:
if (i == TPS65910_REG_VDD1 || i == TPS65910_REG_VDD2) {
pmic-desc[i].ops = tps65910_ops_dcdc;
+
Hi Mark,
On Fri, Nov 04, 2011 at 20:54:11, Mark Brown wrote:
...should be in two separate commits.
Ok
2. struct tps65910_platform_data usage can be avoided
by making use of struct tps65910_board to simplify
driver. Hence remove it
Why is this a simplification? Note that one of
Hi Mark,
On Fri, Nov 04, 2011 at 20:55:59, Mark Brown wrote:
On Fri, Nov 04, 2011 at 02:26:05PM +, Mohammed, Afzal wrote:
Hi Brown,
Ahem.
I am sorry for that if it offended you, not deliberate, this may
have to do with our different cultures, for me it is always a
confusion whether I
Hi Mark,
On Fri, Nov 04, 2011 at 21:48:56, Mark Brown wrote:
So that definitely seems wrong then - n_voltages is supposed to be the
number of voltages that can be selected so if the regulator supports
_NUM_VOLTS steps then I'd expect to see that constant used directly.
Otherwise I'd suggest
Hi Mark,
On Fri, Nov 04, 2011 at 22:10:09, Mark Brown wrote:
What do you mean when you say gain?
Effective voltage expression is (value1 * 12.5mV + 562.5 mV) * value2.
In this value2 is being called as gain.
value1 can have values from 3 to 75, both inclusive (73 steps)
value2 can have
Hi Kyla,
On Thu, Nov 03, 2011 at 22:38:01, Kyle Manna wrote:
The JTAGREVNUM register contains a silicon revision number in the lower
four bits and the upper four bits are to always read 0.
To detect the presence of the device, attempt to read JTAGREVNUM
register and check that it returns a
Hi Tony,
On Sat, Sep 17, 2011 at 07:05:31, Tony Lindgren wrote:
Afzal, care to check if that works for AM335X/TI816X/TI814X?
With following patch over yours, AM335X (the only board with me) boots up fine.
Regards
Afzal
From ff64a239e60f9b517860eb2fe9c4f88a188ca51d Mon Sep 17 00:00:00 2001
Hi Tony,
On Thu, Sep 15, 2011 at 11:12:53, DebBarma, Tarun Kanti wrote:
On Thu, Sep 15, 2011 at 3:15 AM, Tony Lindgren t...@atomide.com wrote:
* Tarun Kanti DebBarma tarun.ka...@ti.com [110908 13:36]:
removed from timer code. New set of timers present on
OMAP4 are now supported.
Also, as
Hi,
This is regarding board with multiple variations using an upcoming SoC from TI.
Variation of the board is detected by reading EEPROM using I2C after
init_machine gets invoked. In one of the variation UART# used is different.
Because of this decompressor logs (and early prints) can't be
201 - 299 of 299 matches
Mail list logo
