Hi,
On Tuesday 06 December 2011 02:12:47 you wrote:
> Hi,
>
> On Tue, Dec 6, 2011 at 1:05 AM, Pali Rohár wrote:
> > I started writing other implementaion of bq2415x charger driver, which
> > should support also setting usb host mode. Code is still unfinished,
> > but now is devided into 2 parts:
On Monday 05 December 2011 04:27 PM, Mark Brown wrote:
On Mon, Dec 05, 2011 at 04:14:40PM +0530, Thomas Abraham wrote:
On 5 December 2011 16:04, Mark Brown
With the regulator device tree bindings if the regulator is configured
to run a single voltage the bindings will set apply_uV uncondition
Hi,
On Mon, Dec 5, 2011 at 10:37 PM, Arnd Bergmann wrote:
> On Sunday 04 December 2011, Ming Lei wrote:
>> >
>> > This data structure is not 32/64 bit safe: running a 64 bit kernel with 32
>> > bit
>> > user space will see an incompatible layout.
>>
>> I agree that this is not 32/64 bit safe, bu
On Mon, 5 Dec 2011, Paul Walmsley wrote:
> For example, here's a trivial implementation for rate recalculation for a
> integer divider clock node (that can't be handled with a right shift):
>
> s64 div(struct clk *clk, u32 div) {
> if (clk->flags & CLK_PARENT_RATE_MAX_U32)
>
On Tue, Dec 06, 2011 at 00:37:38, Hilman, Kevin wrote:
[...]
> >
> > We want to use the existing OMAP implementation of cpufreq (and DVFS) on
> > the devices which do not have VC/VP.
> >
> > The current OMAP cpufreq code under drivers/ invokes clk_set_rate().
> >
> > We had a look at the future DV
Hi,
2011/12/6 Sebastian Reichel :
> Good to hear somebody is working on this :) I planned to do this
> myself, but didn't find any time for it. Here are some comments
> from me:
:)
> [...]
>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>
> I would expect the driver in drivers/power.
Hi,
Good to hear somebody is working on this :) I planned to do this
myself, but didn't find any time for it. Here are some comments
from me:
[...]
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
I would expect the driver in drivers/power. But maybe MFD is
better, since the chip can al
On Mon, 5 Dec 2011, Russell King - ARM Linux wrote:
> On Mon, Dec 05, 2011 at 02:15:56PM -0700, Paul Walmsley wrote:
>
> > But I'd propose that we instead increase the size of struct clk.rate to be
> > s64:
> >
> > s64 clk_round_rate(struct clk *clk, s64 desired_rate);
> > int clk_set_rate(struc
Hi,
On Tue, Dec 6, 2011 at 1:05 AM, Pali Rohár wrote:
> I started writing other implementaion of bq2415x charger driver, which should
> support also setting usb host mode. Code is still unfinished, but now is
> devided into 2 parts: one power_supply driver and one driver which cover all
> bq regi
On Mon, Dec 05, 2011 at 02:15:56PM -0700, Paul Walmsley wrote:
> The types associated with clock rates in the clock interface
> (include/linux/clk.h) are inconsistent, and we should fix this.
Rubbish. They're different with good reason. Rates are primerily
unsigned quantities - and should be t
On Mon, Nov 21, 2011 at 5:40 PM, Mike Turquette wrote:
> +/**
> + * clk_get_parent - return the parent of a clk
> + * @clk: the clk whose parent gets returned
> + *
> + * Simply returns clk->parent. It is up to the caller to hold the
> + * prepare_lock, if desired. Returns NULL if clk is NULL.
>
On Tuesday 06 December 2011 00:35:41 Felipe Contreras wrote:
> From: Aliaksei Katovich
>
> Hi,
>
> The Nokia N900 has a bunch of stuff regarding the battery: bq27x00 to find
> out the status, and isp1704 to detect what kind of charger is connected to
> the USB port. However, that doesn't charge th
On Tue, Dec 6, 2011 at 12:35 AM, Felipe Contreras
wrote:
> From: Aliaksei Katovich
Er, this was supposed to be Felipe Contreras :)
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo
From: Aliaksei Katovich
Hi,
The Nokia N900 has a bunch of stuff regarding the battery: bq27x00 to find out
the status, and isp1704 to detect what kind of charger is connected to the USB
port. However, that doesn't charge the battery.
That's the job of bq24150. Up until now, this has been done b
On 12/02/2011 04:02 PM, Ming Lei wrote:
> This patch introduces two new IOCTLs and related data
> structure defination which will be used by the coming
> face detection video device.
>
> The two IOCTLs and related data structure are used by
> user space application to retrieve the results of face
Hi Ming,
(I've pruned the Cc list, leaving just the mailing lists)
On 12/02/2011 04:02 PM, Ming Lei wrote:
> This patch introduces one driver for face detection purpose.
>
> The driver is responsible for all v4l2 stuff, buffer management
> and other general things, and doesn't touch face detecti
Hi
a brief comment concerning clock rates:
On Mon, 21 Nov 2011, Mike Turquette wrote:
> +unsigned long clk_get_rate(struct clk *clk)
...
> +long clk_round_rate(struct clk *clk, unsigned long rate)
...
> +int clk_set_rate(struct clk *clk, unsigned long rate)
...
> +struct clk {
...
> +
Tero Kristo writes:
> On Fri, 2011-12-02 at 15:55 -0800, Kevin Hilman wrote:
>> Tero Kristo writes:
>>
>> > OMAP3 uses the default settings for VDD1 channel, otherwise the settings
>> > will
>> > overlap with VDD2 and attempting to modify VDD1 voltage will actually
>> > change
>> > VDD2 volta
"Bedia, Vaibhav" writes:
> Hi Kevin,
>
> On Sat, Dec 03, 2011 at 03:57:57, Hilman, Kevin wrote:
> [...]
>> >
>> > Any comments on this approach?
>>
>> Sorry, I didn't see this patch before, and I don't see it in the
>> linux-omap archives either. Not sure what happened there...
>>
>> > This e
From: Felipe Contreras
Seems the commit 7e89098 was overly aggressive in adding iva and mailbox
hwmods so now they are registered twice.
[ cut here ]
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1959
omap_hwmod_register+0x104/0x12c()
omap_hwmod: iva: _register returned -
Should probably have CC'ed linux-omap.
On Mon, Dec 5, 2011 at 7:23 PM, Felipe Contreras
wrote:
> From: Felipe Contreras
>
> This reverts commit 10299e2e4e3ed3b16503d4e04edd48b33083f4e2.
>
> This seems to break USB networking stuff.
>
> Cc: Kalle Jokiniemi
> Cc: Heikki Krogerus
> Cc: Anton Voro
Hi Kevin,
On Sat, Dec 03, 2011 at 03:57:57, Hilman, Kevin wrote:
[...]
> >
> > Any comments on this approach?
>
> Sorry, I didn't see this patch before, and I don't see it in the
> linux-omap archives either. Not sure what happened there...
>
> > This enables us to make use of generic regulato
On Mon, Dec 05, 2011 at 03:45:04PM +0200, Peter Ujfalusi wrote:
> On 12/03/2011 01:22 PM, Mark Brown wrote:
> > Actually thinking about this some more I think what's concerning me is
> > the documentation as much as anything else - if it was just an internal,
> > unpublished interface of the OMAP
On Mon, Dec 05, 2011 at 04:21:21PM +0200, Ohad Ben-Cohen wrote:
> Hi Joerg,
>
> On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg wrote:
> > On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
> >> Ohad Ben-Cohen (5):
> >> ARM: dev_archdata: add private iommu extension
> >> ARM: OMA
On Sunday 04 December 2011, Ming Lei wrote:
> >
> > This data structure is not 32/64 bit safe: running a 64 bit kernel with 32
> > bit
> > user space will see an incompatible layout.
>
> I agree that this is not 32/64 bit safe, but I understand lib32 can handle
> this correctly, otherwise many 32
In a HW system, resources in general have name to identify them.
The is the case as well for IORESOURCE_IRQ resources filled by DT
"interrupts" entries.
The current DT mechanism is relying on the "interrupts" order to identify
the proper resource. This is error prone and not the natural way to
retr
In a HW system, resources in general have name to identify them.
The is the case as well for IOMEM resources filled by DT "reg" entries.
The current DT mechanism is relying on the "reg" order to identify
the proper resource. This is error prone and not the natural way to
retrieve an information in
The current implementation just ignore any NULL string inserted in a
multiple strings property.
In some cases we can have a property with a fix number of strings but
not necessarily used, like for example in a list of valid pinmux modes.
prop = "uart_rx", "uart_tx", "", "", "safe_mode";
Do no sk
Hi Grant & Rob,
Following the previous patch submission [1], here is an updated series
that adds the support for both reg and irq names.
A small improvement is done as well on the property with multiple strings
helper function.
Please note that I've just realized that Russell's concern with the
/
Hi Joerg,
On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg wrote:
> On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
>> Ohad Ben-Cohen (5):
>> ARM: dev_archdata: add private iommu extension
>> ARM: OMAP: omap_device: add a method to set iommu private archdata
>> ARM: OMAP: iom
On Mon, Nov 7, 2011 at 7:19 PM, DebBarma, Tarun Kanti
wrote:
> On Fri, Nov 4, 2011 at 10:10 PM, Kevin Hilman wrote:
>> Tarun Kanti DebBarma writes:
>>
>>> Currently debounce clock state is not tracked in the system.
>>
>> ??
>>
>> bank->dbck_enable_mask ?
> As I understand, this only tells which
On 12/03/2011 01:22 PM, Mark Brown wrote:
> On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
>
>> @@ -0,0 +1,13 @@
>> +* Texas Instruments OMAP4 Digital Microphone Module
>> +
>> +Required properties:
>> + - compatible : "ti,omap4-dmic"
>> + - ti,hwmods : List of hwmod names asso
On 5 December 2011 16:27, Mark Brown
wrote:
> On Mon, Dec 05, 2011 at 04:14:40PM +0530, Thomas Abraham wrote:
>> On 5 December 2011 16:04, Mark Brown
>
>> > With the regulator device tree bindings if the regulator is configured
>> > to run a single voltage the bindings will set apply_uV unconditio
On Mon, Dec 05, 2011 at 04:14:40PM +0530, Thomas Abraham wrote:
> On 5 December 2011 16:04, Mark Brown
> > With the regulator device tree bindings if the regulator is configured
> > to run a single voltage the bindings will set apply_uV unconditionally
> > so there's no need for a separate constra
On 5 December 2011 16:04, Mark Brown
wrote:
> On Mon, Dec 05, 2011 at 02:40:50PM +0530, Thomas Abraham wrote:
>> On 4 December 2011 21:24, Mark Brown
>
>> > If the regulator isn't software managed then always_on covers this - the
>> > regulator core will enable any always_on regulators that haven'
On Mon, Dec 05, 2011 at 02:40:50PM +0530, Thomas Abraham wrote:
> On 4 December 2011 21:24, Mark Brown
> > If the regulator isn't software managed then always_on covers this - the
> > regulator core will enable any always_on regulators that haven't been
> > enabled already.
> Thanks for the hint.
On Mon, Dec 5, 2011 at 10:11 AM, Jan Weitzel wrote:
> Sorry, I wasn't carefully enough. I missed 7a559c78 where you removed
> options from struct omap_nand_platform_data. Did you think getting we
> should reintroduce it? I am looking for a good way to get
> NAND_NO_SUBPAGE_WRITE from boardfile to
On Fri, 2011-12-02 at 15:55 -0800, Kevin Hilman wrote:
> Tero Kristo writes:
>
> > OMAP3 uses the default settings for VDD1 channel, otherwise the settings
> > will
> > overlap with VDD2 and attempting to modify VDD1 voltage will actually change
> > VDD2 voltage.
> >
> > Signed-off-by: Tero Kris
Hi Mark,
On 4 December 2011 21:24, Mark Brown
wrote:
> On Sun, Dec 04, 2011 at 06:51:23PM +0530, Thomas Abraham wrote:
>
>> For regulators that are not turned on by bootloader, and which require
>> 'apply_uV' constraint, is there any alternative for turning on the
>> regulator when using dt?
>
>
Am Freitag, den 02.12.2011, 12:20 +0200 schrieb Grazvydas Ignotas:
> On Thu, Dec 1, 2011 at 10:42 AM, Artem Bityutskiy wrote:
> > On Tue, 2011-11-29 at 10:00 +0100, Jan Weitzel wrote:
> >> Signed-off-by: Jan Weitzel
> >
> > Pushed to l2-mtd-2.6.git, thank you!
>
> This breaks build here, did you
40 matches
Mail list logo
