On Tuesday 24 March 2015 01:09 AM, Nishanth Menon wrote:
From: Keerthy
Add bandgap and related thermal nodes. The patch adds 5 thermal
sensors. Only one cooling device for mpu as of now. The sensors are
the exact same on both dra72 and dra7. Introduce CPU, GPU, core nodes
for the moment as th
of the bounce page")
> >
> > Can you try again with the latest -next please? We've merged an additional
> > patch aimed at sorting this out. Reverting isn't really an option, as
> > there's an awful lot of code that depends on the bounce page removal.
>
* Eduardo Valentin [150324 08:17]:
> On Mon, Mar 23, 2015 at 02:39:39PM -0500, Nishanth Menon wrote:
> > BeagleBoard-X15 has capability for a fan and has an onboard TMP102
> > temperature sensor as well. This allows us to create a new thermal
> > zone (called, un-imaginatively "board"), and allows
* Sebastian Reichel [150321 13:20]:
> From: Sebastian Reichel
>
> This adds support for the N900's accelerometer to
> the Nokia N900 DTS file.
>
> Signed-off-by: Sebastian Reichel
This at least currently does not conflict with anything I have
queued, so I suggest you try to get Greg to take t
On 03/26/2015 07:30 PM, Tony Lindgren wrote:
* Tero Kristo [150326 03:55]:
On 03/26/2015 09:24 AM, Tero Kristo wrote:
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed
* Kishon Vijay Abraham I [150317 04:25]:
> As per the TRMs of AM572x, OMAP4430, OMAP4460, OMAP543x, the value of
> SYNC2 must be set to 0x6 in order to ensure correct operation.
>
> So modified the SYNC2 value of OCP2SCP TIMING register to 0x6 in all the
> platforms that use OCP2SCP driver except
* Nishanth Menon [150325 16:32]:
> On 03/25/2015 06:25 PM, Praneeth Bajjuri wrote:
> > ARM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable
> > the same in the build.
> >
> > DRA7xx is based on Cortex-A15 r2p2 revision.
> >
> > ARM Errata extract and workaround information is
* Stefan Agner [150321 17:00]:
> The NULL pointer check for superset->muxnames will always evaluate
> true since muxnames is an array within struct omap_mux. Remove the
> superfluous check to avoid warnings when using LLVM/clang.
>
> Signed-off-by: Stefan Agner
Applying into omap-for-v4.1/fixes
* Tero Kristo [150326 03:55]:
> On 03/26/2015 09:24 AM, Tero Kristo wrote:
> >On 03/26/2015 01:17 AM, Tony Lindgren wrote:
> >>* Tero Kristo [150325 08:12]:
> >>>
> >>>Splits the clock provider init out of the PRM driver and moves it to
> >>>clock driver. This is needed so that once the PRCM driv
On Thu, Mar 26, 2015 at 03:38:25PM +0200, Jyri Sarha wrote:
> From: Manish Badarkhe
>
> As davinci card gets registered using 'devm_' api
> there is no need to unregister the card in 'remove'
> function.
> Hence drop the 'remove' function.
Not only that but the current remove function creates a
* Matthijs van Duin [150326 00:02]:
> On 26 March 2015 at 00:36, Kishon Vijay Abraham I wrote:
> > Let me know if you find any problems with this patch.
>
> I spotted a minor issue in drivers/phy/Kconfig:
>
> > + Enable this for dm81xx USB to work.
>
> This should say dm816x instead.
On Thu, Mar 26, 2015 at 02:31:30PM +0200, Peter Ujfalusi wrote:
> On 03/26/2015 12:56 PM, Vinod Koul wrote:
> >> +#define TI_XBAR_OUTPUTS 127
> >> +#define TI_XBAR_INPUTS256
> > Ideally this should be moved to DT. Will next revision of this chip always
> > support these output and inputs?
>
On Thu, Mar 26, 2015 at 02:11:38PM +0200, Peter Ujfalusi wrote:
> On 03/26/2015 12:50 PM, Vinod Koul wrote:
> > On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote:
> >> DMA routers are transparent devices used to mux DMA requests from
> >> peripherals to DMA controllers. They are used w
sorting this out. Reverting isn't really an option, as
> there's an awful lot of code that depends on the bounce page removal.
Here are the kernelci.org -next results[1], if you click the build
status you can dig down into the build failures. next-20150326 has now
hit a compiler bug, Arn
* Peter Ujfalusi [150326 05:32]:
> On 03/26/2015 12:56 PM, Vinod Koul wrote:
> >> +
> >> +static void ti_dma_xbar_free(struct device *dev, void *route_data)
> >> +{
> >> + struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
> >> + struct ti_dma_xbar_map *map = route_data;
> >> +
> >> + dev_db
From: Manish Badarkhe
As davinci card gets registered using 'devm_' api
there is no need to unregister the card in 'remove'
function.
Hence drop the 'remove' function.
Signed-off-by: Manish Badarkhe
Signed-off-by: Jyri Sarha
---
sound/soc/davinci/davinci-evm.c | 10 --
1 file changed,
On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote:
> On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote:
> > I think we now have a new error: (seen with omap2plus_defconfig)
> > on next-20150324 :
> > ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size'
> >
On 03/26/2015 12:57 PM, Vinod Koul wrote:
> On Wed, Mar 11, 2015 at 03:23:27PM +0200, Peter Ujfalusi wrote:
>> Instead of magic numbers in the code, use define for number of logical DMA
>> channels and DMA requests.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> drivers/dma/omap-dma.c | 7 +--
On 03/26/2015 12:56 PM, Vinod Koul wrote:
>> +#define TI_XBAR_OUTPUTS 127
>> +#define TI_XBAR_INPUTS 256
> Ideally this should be moved to DT. Will next revision of this chip always
> support these output and inputs?
They are coming from DT. I'm using these as fall back values in case we
On 03/26/2015 12:50 PM, Vinod Koul wrote:
> On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote:
>> DMA routers are transparent devices used to mux DMA requests from
>> peripherals to DMA controllers. They are used when the SoC integrates more
>> devices with DMA requests then their cont
On Wed, Mar 11, 2015 at 03:23:27PM +0200, Peter Ujfalusi wrote:
> Instead of magic numbers in the code, use define for number of logical DMA
> channels and DMA requests.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/dma/omap-dma.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-
On Wed, Mar 11, 2015 at 03:23:26PM +0200, Peter Ujfalusi wrote:
> The DRA7x has more peripherals with DMA requests than the sDMA can handle:
> 205 vs 127. All DMA requests are routed through the DMA crossbar, which can
> be configured to route selected incoming DMA requests to specific sDMA
> reque
On 03/26/2015 09:24 AM, Tero Kristo wrote:
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed so that once the PRCM drivers are
separated,
they can logically just access t
On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote:
> DMA routers are transparent devices used to mux DMA requests from
> peripherals to DMA controllers. They are used when the SoC integrates more
> devices with DMA requests then their controller can handle.
> DRA7x is one example of su
On 26 March 2015 at 08:38, Ulf Hansson wrote:
> On 26 March 2015 at 02:18, NeilBrown wrote:
>> On Thu, 26 Mar 2015 08:43:37 +1100 NeilBrown wrote:
>>
>>> enable and disable are only used to get and put
>>> runtime pm references. .set_ios already does this
>>> itself, and other drivers just do i
On 26 March 2015 at 02:18, NeilBrown wrote:
> On Thu, 26 Mar 2015 08:43:37 +1100 NeilBrown wrote:
>
>> enable and disable are only used to get and put
>> runtime pm references. .set_ios already does this
>> itself, and other drivers just do it in set_ios
>> and .request without using enable/disa
On Thu, 26 Mar 2015, Kishon Vijay Abraham I wrote:
> On Thursday 19 March 2015 10:19 PM, Paul Walmsley wrote:
> > On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote:
> >> On 03/19/2015 05:45 PM, Paul Walmsley wrote:
> >>> On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote:
> On 03/1
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed so that once the PRCM drivers are separated,
they can logically just access the clock driver not needing to go through
co
On 26 March 2015 at 00:36, Kishon Vijay Abraham I wrote:
> Let me know if you find any problems with this patch.
I spotted a minor issue in drivers/phy/Kconfig:
> + Enable this for dm81xx USB to work.
This should say dm816x instead.
Matthijs
--
To unsubscribe from this list: send the l
29 matches
Mail list logo