On Wed, Jul 05, 2017 at 11:15:01AM -0700, Florian Fainelli wrote:
> On 07/05/2017 10:46 AM, Karl Beldan wrote:
> > From: Karl Beldan
> >
> > Tested on BCM{63138,6838,63268} and cross checked with the various
> > *_map_part.h which the brcmnand_regs_v* in brcmnand.c
From: Karl Beldan
Tested on BCM{63138,6838,63268} and cross checked with the various
*_map_part.h which the brcmnand_regs_v* in brcmnand.c have historically
been derived from.
Cc: Brian Norris
Cc: Kamal Dasu
Cc: Boris Brezillon
Cc: Richard Weinberger
Cc: David Woodhouse
Cc: Marek Vasut
Cc
: store the appended dtb address in a variable")
Cc:
Cc: Ralf Baechle
Cc: Jonas Gorski
Signed-off-by: Karl Beldan
---
arch/mips/kernel/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
index cf05220..d1bb506 100644
: store the appended dtb address in a variable")
Cc:
Cc: Ralf Baechle
Cc: Jonas Gorski
Signed-off-by: Karl Beldan
---
arch/mips/kernel/head.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
index cf05220..d1bb506 100644
On Thu, Dec 15, 2016 at 08:51:06AM +0100, Richard Weinberger wrote:
> On 15.12.2016 08:09, Karl Beldan wrote:
> >>> I think this should also go into -stable.
> >>
> >> Why? Do you have real use cases that are broken by this? I understand
> >
> >
On Wed, Dec 14, 2016 at 9:09 PM, Brian Norris
wrote:
> On Wed, Dec 14, 2016 at 07:24:46PM +0000, Karl Beldan wrote:
>> On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris
>> wrote:
>> > On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote:
>> >>
On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris
wrote:
> On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote:
>> On Wed, 21 Sep 2016 11:43:56 +0200
>> Daniel Walter wrote:
>>
>> > From: Richard Weinberger
>> >
>> > If the master device has callbacks for _get/put_device()
>> > and this
Hi,
On Mon, Oct 31, 2016 at 2:19 PM, Bartosz Golaszewski
wrote:
> The frame synchronization error happens when the DMA engine attempts
> to read what it believes to be the first word of the video buffer but
> it cannot be recognized as such or when the LCDC is starved of data
> due to insufficien
also squashed Karl's two patches and
> removed the panel node.
>
> Tested on a da850-lcdk with an LCD display connected over VGA with
> two patches already posted to the drm mailing list:
>
> drm: tilcdc: add a da850-specific compatible string
> drm: tilcdc: add a workar
Hi,
This has already been reported by Fengguang Wu's kbuild test robot:
https://lists.01.org/pipermail/kbuild-all/2016-July/022203.html
but it seems to have slipped through.
Karl
On Fri, Sep 30, 2016 at 11:42:14AM +0200, Bartosz Golaszewski wrote:
> 2016-09-29 20:40 GMT+02:00 Karl Beldan :
> > Hi,
> >
> > On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
> >> From: Karl Beldan
> >>
> >> This adds the p
On Fri, Sep 30, 2016 at 11:37:57AM +0200, Bartosz Golaszewski wrote:
> 2016-09-29 20:58 GMT+02:00 Karl Beldan :
> > Hi,
> >
> > On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
> >> Add svga timings for 1024x768 resolution to the da850-lcdk
> &g
On Fri, Sep 30, 2016 at 9:31 AM, Bartosz Golaszewski
wrote:
> 2016-09-29 21:07 GMT+02:00 Karl Beldan :
>> Hi,
>>
>> On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
>>> Default memory settings of da850 do not meet the throughput/latency
>>&g
Hi,
On Thu, Sep 29, 2016 at 06:31:55PM +0200, Bartosz Golaszewski wrote:
> Default memory settings of da850 do not meet the throughput/latency
> requirements of tilcdc. This results in the image displayed being
> incorrect and the following warning being displayed by the LCDC
> drm driver:
>
>
Hi,
On Thu, Sep 29, 2016 at 06:31:53PM +0200, Bartosz Golaszewski wrote:
> Add svga timings for 1024x768 resolution to the da850-lcdk
> device tree.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/boot/dts/da850-lcdk.dts | 15 +--
> 1 file changed, 13 insertions(+), 2 deleti
Hi,
On Thu, Sep 29, 2016 at 06:31:52PM +0200, Bartosz Golaszewski wrote:
> From: Karl Beldan
>
> This adds the pins used by the LCD controller, and uses 'tilcdc,panel'
> with some default timings for 800x600.
>
> Tested on an LCDK connected on the VGA port (the LCDC
On Tue, Aug 16, 2016 at 11:20:29PM +, Karl Beldan wrote:
> On Wed, Aug 10, 2016 at 05:23:23PM +0530, Sekhar Nori wrote:
> > On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote:
> > > On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote:
> > >> On Wed
].
[1] 28c015a9daab ("mtd: davinci-nand: disable subpage write for keystone-nand")
Signed-off-by: Karl Beldan
---
drivers/mtd/nand/davinci_nand.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index cc07ba0..27fa
On Thu, Aug 18, 2016 at 03:27:52PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 04:30 PM, Karl Beldan wrote:
> > This adds DT support for the NAND connected to the SoC AEMIF.
> > The parameters (timings, ecc) are the same as what the board ships with
> > (default AE
On Wed, Aug 17, 2016 at 04:08:03PM +0530, Sekhar Nori wrote:
> On Wednesday 17 August 2016 03:43 PM, Karl Beldan wrote:
> > On Wed, Aug 17, 2016 at 02:20:51PM +0530, Sekhar Nori wrote:
> >> On Thursday 11 August 2016 01:38 AM, Karl Beldan wrote:
> >>> This is the min
On Wed, Aug 17, 2016 at 03:24:42PM +0530, Sekhar Nori wrote:
> On Thursday 11 August 2016 01:38 AM, Karl Beldan wrote:
> > The LCDK embeds a TLV320AIC3106 connected to the SoC McASP for analog
> > audio. This relies on the 'dummy' regulator as the codec is always on.
On Wed, Aug 17, 2016 at 02:20:51PM +0530, Sekhar Nori wrote:
> On Thursday 11 August 2016 01:38 AM, Karl Beldan wrote:
> > This is the minimal set of additional modules required to support audio
> > on the LCDK.
> >
> > Signed-off-by: Karl Beldan
>
> This p
On Wed, Aug 10, 2016 at 05:23:23PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 04:49 PM, Karl Beldan wrote:
> > On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote:
> >> On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote:
> >>> On Wed, Au
On Wed, Aug 10, 2016 at 02:04:48PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
> > On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
> >> On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
> >>> On Wed, Au
On Wed, Aug 10, 2016 at 11:00:31AM +, Karl Beldan wrote:
> Currently the davinci da8xx boards use the mach-davinci aemif code.
> Instantiating an aemif node into the DT allows to use the ti-aemif
> memory driver and is another step to better DT support.
> This change adds an aemif
same clock:
'CLK(NULL, "aemif",&aemif_clk)'
remains, as it is currently used (davinci_nand is getting a named clock
"aemif").
This change will allow to switch from the mach-davinci aemif code to
the ti-aemif memory driver.
Signed-off-by: Kar
On Wed, Aug 10, 2016 at 07:00:20AM +, Karl Beldan wrote:
> On Tue, Aug 09, 2016 at 05:15:15PM +0000, Karl Beldan wrote:
> > Many davinci boards (da830 and da850 families) don't have their clocks
> > in DT yet and won't be successful in getting an unnamed aemif clock.
This enables the use of the memory/ti-aemif.c driver.
ATM most davinci boards use the mach-davinci aemif code which gets in
the way of genericity and proper DT boot.
Signed-off-by: Karl Beldan
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch
This is the minimal set of additional modules required to support audio
on the LCDK.
Signed-off-by: Karl Beldan
---
arch/arm/configs/davinci_all_defconfig | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig
b/arch/arm/configs/davinci_all_defconfig
The LCDK embeds a TLV320AIC3106 connected to the SoC McASP for analog
audio. This relies on the 'dummy' regulator as the codec is always on.
Quality is good with arecord -pipe- aplay on Line In/Line Out.
The MIC path doesn't seem to work yet.
Signed-off-by: Karl Beldan
---
ar
On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
> > On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
> >> On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
> >>> On Tuesday
On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
> > On Wed, Aug 10, 2016 at 01:42:01PM +0530, Sekhar Nori wrote:
> >> On Wednesday 10 August 2016 01:37 PM, Karl Beldan wrote:
> >>> On Wed, Au
On Wed, Aug 10, 2016 at 02:04:48PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
> > On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
> >> On Wednesday 10 August 2016 01:56 PM, Karl Beldan wrote:
> >>> On Wed, Au
On Wed, Aug 10, 2016 at 01:18:51PM +0530, Sekhar Nori wrote:
> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
> > Currently the davinci da8xx boards use the mach-davinci aemif code.
> > Instantiating an aemif node into the DT allows to use the ti-aemif
> > memory drive
On Wed, Aug 10, 2016 at 01:32:03PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 01:18 PM, Sekhar Nori wrote:
> > On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
> >> Currently the davinci da8xx boards use the mach-davinci aemif code.
> >> Instantiatin
On Tue, Aug 09, 2016 at 05:15:17PM +, Karl Beldan wrote:
> This adds DT support for the NAND connected to the SoC AEMIF.
> The parameters (timings, ecc) are the same as what the board ships with
> (default AEMIF timings, 1bit ECC) and improvements will be handled in
> due course.
&
On Wed, Aug 10, 2016 at 09:28:48AM +, Karl Beldan wrote:
> On Wed, Aug 10, 2016 at 02:04:48PM +0530, Sekhar Nori wrote:
> > On Wednesday 10 August 2016 02:04 PM, Karl Beldan wrote:
> > > On Wed, Aug 10, 2016 at 01:59:26PM +0530, Sekhar Nori wrote:
> > >> On Wed
On Wed, Aug 10, 2016 at 03:01:30PM +0530, Sekhar Nori wrote:
> On Wednesday 10 August 2016 02:34 PM, Karl Beldan wrote:
> > On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
> >> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
> >>> This adds DT sup
in the dts as a subnode of the aemif
one along with its pins.
Signed-off-by: Karl Beldan
---
arch/arm/boot/dts/da850-evm.dts | 49 -
arch/arm/boot/dts/da850.dtsi| 19 +++-
2 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/arch
On Tue, Aug 09, 2016 at 05:15:15PM +, Karl Beldan wrote:
> Many davinci boards (da830 and da850 families) don't have their clocks
> in DT yet and won't be successful in getting an unnamed aemif clock.
> Also the sole current users of ti-aemif (keystone boards) use '
lookup for clock matching"
- Make the same improvements for the EVM (and retire nand_cs3)
Karl Beldan (4):
ARM: davinci: da8xx-dt: Add ti-aemif lookup for clock matching
ARM: davinci_all_defconfig: Enable AEMIF as a module
ARM: dts: da850,da850-evm: Add an aemif node and use it for the NA
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote:
> On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote:
> > This adds DT support for the NAND connected to the SoC AEMIF.
> > The parameters (timings, ecc) are the same as what the board ships with
> > (default AE
.
Signed-off-by: Karl Beldan
---
arch/arm/boot/dts/da850-lcdk.dts | 107 +++
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index dbcca0b..a3f9845 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b
.
Signed-off-by: Karl Beldan
---
arch/arm/boot/dts/da850-lcdk.dts | 108 +++
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index dbcca0b..033380b 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b
Hi,
This does not use the same way the current da8xx boards do, instead
it is using the more generic and DT friendly memory driver ti-aemif.
I can do the same for the da850-evm and retire the dts nandcs3 instances.
Karl Beldan (4):
memory: ti-aemif: Get a named clock rather than an unnamed one
This enables the use of the memory/ti-aemif.c driver.
ATM most davinci boards use the mach-davinci aemif code which gets in
the way of genericity and proper DT boot.
Signed-off-by: Karl Beldan
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch
cted.
Signed-off-by: Karl Beldan
---
drivers/memory/ti-aemif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index a579a0f..c251fc8 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -345,7 +345,7 @@ st
Currently the davinci da8xx boards use the mach-davinci aemif code.
Instantiating an aemif node into the DT allows to use the ti-aemif
memory driver and is another step to better DT support.
Also it will allow to properly pass the emif timings via DT.
Signed-off-by: Karl Beldan
---
arch/arm
On Thu, Apr 09, 2015 at 04:46:28PM +0800, l...@kernel.org wrote:
> From: karl beldan
>
> 3.4.107-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
>
> commit 150ae0e94634714b23919f0c333fee28a5b199d5 upstream.
>
On Wed, Feb 18, 2015 at 09:40:23AM +, David Laight wrote:
> From: Karl Beldan
> > On Tue, Feb 17, 2015 at 12:04:22PM +, David Laight wrote:
> > > > +static inline u32 from64to32(u64 x)
> > > > +{
> > > > + /* add up 32-bit and
On Tue, Feb 17, 2015 at 12:04:22PM +, David Laight wrote:
> > +static inline u32 from64to32(u64 x)
> > +{
> > + /* add up 32-bit and 32-bit for 32+c bit */
> > + x = (x & 0x) + (x >> 32);
> > + /* add up carry.. */
> > + x = (x & 0x) + (x >> 32);
> > + return (u32)x;
>
rted-by: kbuild test robot
Signed-off-by: Karl Beldan
Cc: Eric Dumazet
Cc: David S. Miller
---
lib/checksum.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/lib/checksum.c b/lib/checksum.c
index fcf3894..8b39e86 100644
--- a/lib/checksum.c
+++ b/lib/checks
On Wed, Jan 28, 2015 at 10:32:49PM -0800, David Miller wrote:
> From: Karl Beldan
> Date: Wed, 28 Jan 2015 10:58:11 +0100
>
> > The carry from the 64->32bits folding was dropped, e.g with:
> > saddr=0x daddr=0xFFFF len=0x proto=0 sum=1,
> > csum_tc
The carry from the 64->32bits folding was dropped, e.g with:
saddr=0x daddr=0xFFFF len=0x proto=0 sum=1,
csum_tcpudp_nofold returned 0 instead of 1.
Signed-off-by: Karl Beldan
Cc: Al Viro
Cc: Eric Dumazet
Cc: Arnd Bergmann
Cc: Mike Frysinger
Cc: net...@vger.kernel.org
On Tue, Jan 27, 2015 at 10:03:32PM +, Al Viro wrote:
> On Tue, Jan 27, 2015 at 04:25:16PM +0100, Karl Beldan wrote:
> > The carry from the 64->32bits folding was dropped, e.g with:
> > saddr=0x daddr=0xFFFF len=0x proto=0 sum=1
> >
> > Signed-off
The carry from the 64->32bits folding was dropped, e.g with:
saddr=0x daddr=0xFFFF len=0x proto=0 sum=1
Signed-off-by: Karl Beldan
Cc: Mike Frysinger
Cc: Arnd Bergmann
Cc: linux-kernel@vger.kernel.org
Cc: Stable
---
lib/checksum.c | 4 ++--
1 file changed, 2 insertions(+)
On 7/31/12, Russell King - ARM Linux wrote:
> On Tue, Jul 31, 2012 at 09:31:13PM +0200, Karl Beldan wrote:
>> On 7/31/12, Russell King - ARM Linux wrote:
>> > On Tue, Jul 31, 2012 at 08:45:57AM +0200, Karl Beldan wrote:
>> >> I was expecting the following to work:
On 7/31/12, Russell King - ARM Linux wrote:
> On Tue, Jul 31, 2012 at 08:45:57AM +0200, Karl Beldan wrote:
>> I was expecting the following to work:
>> addr = dma_map_single(dev, buffer, size, DMA_TO_DEVICE);
>> dma_sync_single_for_device(dev, buffer, pattern_
On Tue, Jul 31, 2012 at 09:34:01AM +0200, Clemens Ladisch wrote:
> Karl Beldan wrote:
> > On 7/31/12, Clemens Ladisch wrote:
> >> Karl Beldan wrote:
> >>> To tx a chunk of data from the SoC => network device, we :
> >>> - prepare a buffer with a leadin
On 7/31/12, Clemens Ladisch wrote:
> Karl Beldan wrote:
>> To tx a chunk of data from the SoC => network device, we :
>> - prepare a buffer with a leading header embedding a pattern,
>> - trigger the xfer and wait for an irq
>> // The device updates the pattern and
Hi,
(This is an email originally addressed to the linux-kernel
mailing-list.)
On our board we've got an MV78200 and a network device between which we
xfer memory chunks via the ddram with an external dma controller.
To handle these xfers we're using the dma API.
To tx a chunk of data from the
On Mon, Jul 30, 2012 at 10:24:01PM +0200, karl.bel...@gmail.com wrote:
> I was expecting the following to work:
> addr = dma_map_single(dev, buffer, size, DMA_TO_DEVICE);
Sorry, I forgot this (invalidate):
dma_sync_single_for_device(dev, buffer, pattern_size, DMA_FROM_DEVICE);
>
Hi,
On our board we've got an MV78200 and a network device between which we
xfer memory chunks via the ddram with an external dma controller.
To handle these xfers we're using the dma API.
To tx a chunk of data from the SoC => network device, we :
- prepare a buffer with a leading header embeddi
63 matches
Mail list logo
