On Thursday 16 February 2012, Turquette, Mike wrote:
Ah, one more, would be better to us if arm-soc tree could provide
the topic branch for 'common struct clk' working as a base.
Good point. Mike, can you send a pull request for whatever you have
now as another staging branch for
On Saturday 11 February 2012, Mark Brown wrote:
On Sat, Feb 11, 2012 at 08:07:08PM +, Arnd Bergmann wrote:
what the risk is in changing exynos4 at the same time. It would
be great if we can have all exynos use the common struct clk in 3.4,
but I'm also happy if we just get exynos5
On Saturday 11 February 2012, Kukjin Kim wrote:
Please pull samsung fixes-3 for v3.3.
There are regarding exynos dt fixes.
If any problems, please let me know.
The following changes since commit d65b4e98d7ea3038b767b70fe8be959b2913f16d:
Linux 3.3-rc3 (2012-02-08 19:21:53 -0800)
On Saturday 11 February 2012, Kukjin Kim wrote:
Please pull samsung rtc developing which has been missed to upstream.
I rebased it Olof said and there is no conflicts with
arm-soc/depends/rmk/for-armsoc.
If any problem, please kindly let me know.
Thanks.
Best regards,
Kgene.
--
On Friday 10 February 2012, Rafael J. Wysocki wrote:
Rafael, do you want to keep the option of rebasing the patches that you
got from Kukjin?
No, I'm not going to rebase them.
Ok, very good!
If your workflow requires that, I can't take them, but
if you can guarantee that the branch
On Friday 10 February 2012, Santosh Y wrote:
UFS host controller specification Section 7.2.1, step 11, mentions
that the aggregation control register should be set if run/stop bit is
not enabled.
But In this case the run/ stop bit is set above before configuring the
aggregation
On Saturday 11 February 2012, Kukjin Kim wrote:
This patch adds clock-exynos5.c for EXYNOS5250 now
and that can be used for other EXYNOS5 SoCs later.
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/clock-exynos5.c | 1252
On Friday 10 February 2012, Rafael J. Wysocki wrote:
On Friday, February 10, 2012, Kukjin Kim wrote:
Hi Arnd, Olof,
Please pull samsung exynos pm domains.
It has been merged into linux-pm tree by Rafael and I think it should be
pulled into arm-soc.
No, this doesn't work like
On Thursday 09 February 2012, Kukjin Kim wrote:
Will Deacon wrote:
On Wed, Feb 01, 2012 at 08:50:23AM +, Olof Johansson wrote:
On Tue, Jan 31, 2012 at 8:20 PM, Kyungmin Park kmp...@infradead.org
wrote:
As I remember only DT based board file is acceptable for mainline?
For
On Wednesday 01 February 2012, Kyungmin Park wrote:
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 3b07fb9..c55e5fb 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1594,7 +1594,7 @@ static struct s3c24xx_serial_drv_data
host controller to process requests
- Enable required interrupts
- Configure interrupt aggregation
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Reviewed-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Saugata Das saugata
On Monday 09 January 2012, Kukjin Kim wrote:
In my opinion, as you know, it would be better to us if you could send this in
this merge window.
Actually, it does not have any dependency with others, in addition, for a long
time this has been included in linux-next for this
merge window.
Your
On Monday 02 January 2012, Kukjin Kim wrote:
Hi Arnd and Olof,
Please pull Samsung devel-dma for v3.3 from following:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-samsung-devel-dma
Its major feature is including merge of pl330 driver into drivers/dma/ and
On Tuesday 27 December 2011, Kukjin Kim wrote:
Please pull the samsung-devel-ohci for v3.3.
The USB stuff got the ack from Greh and he agreed to send to upstream via
samsung tree.
If any problems, please let me know.
Pulled, thanks!
Arnd
--
To unsubscribe from this list: send the
On Saturday 24 December 2011, Kukjin Kim wrote:
Please pull the samsung-cleanup-spi for v3.3.
It depends on samsung-devel-spi3 branch...
If any problems, please let me know.
I've applied next-samsung-cleanup-mmc2, next-samsung-devel-spi3 and
next-samsung-cleanup-spi4, all into next/cleanup2
On Tuesday 27 December 2011, Kukjin Kim wrote:
Hi Arnd and Olof,
Please pull the Samsung-devel-mmc-spi for v3.3.
It depends on Samsung-cleanup-spi4 branch as well.
If any problems, please let me know.
Pulled into next/drivers branch.
Thanks,
Arnd
--
To unsubscribe from this
On Monday 21 November 2011, Kukjin Kim wrote:
Please pull samsung-fixes for v3.2 from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
samsung-fixes
This includes fix of inclusion header.
If any problems, please let me know.
Pulled, thanks!
On Monday 21 November
On Sunday 06 November 2011, Kukjin Kim wrote:
As I replied, I re-based 'next-samsung-exynos' based on latest mainline.
So changes since previous pull request:
The following changes since commit c861cd3e92d92ae946e19099f198018fcb4fd887:
Merge branch 'next/devel2' of
Hi Linus,
Thanks for pulling the two previous sets of samsung patches, I've just seen
them show up and Kukjin Kim has already provided a patch on top of that
to do the move I mentioned in the previous pull request.
This moves all files from mach-exynos4 to mach-exynos in preparation for
future
On Friday 04 November 2011, Kukjin Kim wrote:
As we talked in Prague, I'm sending 'pull request for v3.2' Samsung-devel4
which includes supporting EXYNOS4 DT, SPI clkdev and reorganization
arch/arm/mach-exynos and small things.
Please pull from:
git://github.com/kgene/linux-samsung.git
On Saturday 05 November 2011, Kukjin Kim wrote:
Arnd Bergmann wrote:
Please send the contents split up into separate branches (dt, spi, clkdev,
rename, devel) for 3.3. I think it's ok if you want to send just the
rename patch for 3.2 the way we had discussed earlier, because this kind
On Monday 17 October 2011, Kukjin Kim wrote:
This is for Samsung devel stuff for v3.2 and based on previous
next-samsung-devel-2.
Please pull from:
git://github.com/kgene/linux-samsung.git next-samsung-devel-3
If any problems, please let me know.
As a note, I need to sort out DT
On Saturday 08 October 2011 18:17:49 Eric Miao wrote:
To check inconsistencies, the Makefile compares .tmp_System.map and
System.map for differences.
On a normal build they should be identical, but if this fails with
Inconsistent kallsyms data you could try comparing the two files to
On Monday 03 October 2011, Kukjin Kim wrote:
Mark Brown wrote:
On Sun, Oct 02, 2011 at 06:25:36PM +0900, Kukjin Kim wrote:
gpio/samsung: gpio-samsung.c to support Samsung GPIOs
As I reported the other day this change breaks the boot early on on the
Cragganmore S3C6410
On Tuesday 04 October 2011, Kukjin Kim wrote:
This is a second Samsung board stuff for v3.2 and includes new board,
SMDK4412.
Please pull from:
git://github.com/kgene/linux-samsung.git next-samsung-board-2
As a note, since supporting SMDK4412 needs previous next-samsung-board
branch so
On Tuesday 04 October 2011, Kukjin Kim wrote:
This is second cleanup for Samsung stuff for v3.2 and includes cleanup
header files in plat-s3c24xx and plat-s5p to merge into one plat-samsung
directory.
Please pull from:
git://github.com/kgene/linux-samsung.git next-samsung-cleanup-2
And
On Monday 03 October 2011 13:02:16 Kyungmin Park wrote:
I'm afraid to change machine directory name again. mach-s5pv310 -
mach-exynos4 - mach-exynos.
As I remember linus blamed the renaming the file names are happened
frequently at ARM
I tend to agree with this. While the new name does make
On Monday 03 October 2011 21:40:36 Kukjin Kim wrote:
Yes, absolutely. As I said, the 'mach-exynos' can support upcoming
Samsung EXYNOS SoCs and the way is better than making mach-exynos5.
My bigger plan is finally to make current directories to 3 mach- dir.
(mach-s3c, mach-s5p, and
On Monday 03 October 2011 12:41:22 Kukjin Kim wrote:
This patch adds macro SAMSUNG_RES_MEM, SAMSUNG_RES_IRQ
and so on to cleanup regarding 'struct resource' by using
defined helpers at linux/ioport.h.
Cc: Ben Dooks ben-li...@fluff.org
Signed-off-by: Kukjin Kim kgene@samsung.com
When we
On Monday 19 September 2011, Kukjin Kim wrote:
This is Samsung cleanup for v3.2.
Please pull from:
git://github.com/kgene/linux-samsung.git next-samsung-cleanup
Pulled into arm-soc/next/cleanup.
If any problems, please let me know.
One tiny conflict with Nico's cross-platform series:
+
On Monday 19 September 2011, Kukjin Kim wrote:
Please pull from:
git://github.com/kgene/linux-samsung.git next-samsung-board
As you see, the next-samsung-board includes new board, SMDK4212. Of course
to support new SoC, EXYNOS4212 is required for it but current
arch/arm/mach-exynos4
On Saturday 17 September 2011 10:08:30 Kukjin Kim wrote:
Arnd Bergmann wrote:
?
The patches are currently queued in the stable branch of the arm-soc
tree, I haven't forwarded them to Linus yet. I can easily change
the changelog before I actually send them on (if you tell me which ones
On Thursday 15 September 2011, Kukjin Kim wrote:
This is Samsung fixes for v3.1
Please pull from:
git://github.com/kgene/linux-samsung.git samsung-fixes-2
As you know, git.kernel.org/master.kernel.org has been down so I use
temporary git repo. at github now.
These things are needed for
On Friday 26 August 2011 10:14:47 Kukjin Kim wrote:
Hi Arnd, any problem?
I can't find this yet in your -fixes branch.
As you said before, if there are fixes in -fixes branch, it should be
handled faster than others.
Maybe missed? Or should I need to send this to Linus directly?...
I
On Friday 19 August 2011, Kukjin Kim wrote:
This is pull request for Samsung fixes for v3.1-rc3.
Please pull Samsung fixes from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
Pulled finally, sorry for the delay on my side.
Arnd
--
To unsubscribe from this
On Friday 29 July 2011 10:48:46 Kukjin Kim wrote:
Hi all,
When build with s5pc100_defconfig, happens following.
...
KSYM.tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux
SYSMAP System.map
SYSMAP .tmp_System.map
Inconsistent kallsyms data
This is a bug - please report
On Friday 29 July 2011 13:30:20 Tomasz Figa wrote:
I have no idea why, but I cannot reproduce the issue anymore, even after make
distclean or starting with a clean tree. A build system bug?
I do not know much technical details about the kernel build system, but might
it be a concurrency
On Thursday 21 July 2011, Kukjin Kim wrote:
Please pull Samsung S5P updates from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
for-arm-soc
Or if you want to merge each branch into arm-soc, please use following.
As per your suggestion, I made following branches in
On Friday 01 July 2011, Mark Brown wrote:
On Fri, Jul 01, 2011 at 05:15:05PM +0200, Linus Walleij wrote:
There is no clean nice ADC subsystem though, and that feels
like a big problem to drivers like this (and no I don't like the AB8500
GPADC living in MFD either) so if you'd like to
On Thursday 21 April 2011, Marek Szyprowski wrote:
On Wednesday, April 20, 2011 6:07 PM Arnd Bergmann wrote:
On Wednesday 20 April 2011, Marek Szyprowski wrote:
The only question is how a device can allocate a buffer that will be most
convenient for IOMMU mapping (i.e. will require least
On Wednesday 20 April 2011, Marek Szyprowski wrote:
On Tuesday, April 19, 2011 4:30 PM Arnd Bergmann wrote:
Sounds good. I think we should put it into a new drivers/iommu, along
with your specific iommu implementation, and then we can convert the
existing ones over to use that.
I see
On Tuesday 19 April 2011, Russell King - ARM Linux wrote:
On Tue, Apr 19, 2011 at 11:02:34AM +0200, Marek Szyprowski wrote:
On Monday, April 18, 2011 4:16 PM Arnd Bergmann wrote:
My feeling is that this is not the right abstraction. Why can't you
just implement the regular dma-mapping.h
(adding Joerg to Cc)
On Tuesday 19 April 2011, Marek Szyprowski wrote:
These look wrong for a number of reasons:
* try_module_get(THIS_MODULE) makes no sense at all, the idea of the
try_module_get is to pin down another module that was calling down,
which I suppose is not needed
On Tuesday 19 April 2011, Roedel, Joerg wrote:
On Tue, Apr 19, 2011 at 08:49:50AM -0400, Arnd Bergmann wrote:
Ok, it looks I don't fully get how this iommu.h should be used. It looks
that there can be only one instance of iommu ops registered in the system,
so only one iommu driver can
On Tuesday 19 April 2011, Marek Szyprowski wrote:
1. change the runtime_pm subsystem to allow it to ignore some devices
in an easy way.
2. change the device layout if the sysmmu. If the iommu device is
a child of the device that it is responsible for, I guess you don't
have this
On Tuesday 19 April 2011, Roedel, Joerg wrote:
Getting back to our video codec - it has 2 IOMMU controllers. The codec
hardware is able to address only 256MiB of space. Do you have an idea how
this can be handled with dma-mapping API? The only idea that comes to my
mind is to provide a
On Monday 18 April 2011, Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- simplified the resource management: no more single platform
device with 32 resources is needed, better fits
On Monday 18 April 2011, Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch adds new videobuf2 memory allocator dedicated to devices that
supports IOMMU DMA mappings. A device with IOMMU module and a driver
with include/iommu.h compatible interface is
On Monday 14 March 2011, KyongHo Cho wrote:
I think we can consider another solution for the various requirements.
I think one of the most possible solutions is VCMM.
Or we can enhance include/linux/iommu.h with reference of VCMM.
I think extending or changing the existing interface would be
On Friday 11 March 2011, Marek Szyprowski wrote:
We followed the style of iommu API for other mainline ARM platforms (both
OMAP and MSM
also have custom API for their iommu modules). I've briefly checked
include/linux/iommu.h
API and I've noticed that it has been designed mainly for KVM
On Friday 11 March 2011, Marek Szyprowski wrote:
The iommu API is not really meant to be KVM specific, it's just that the
in-tree users are basically limited to KVM at the moment. Another user that
is coming up soon is the vmio device driver that can be used to
transparently
pass
On Friday 11 March 2011, Marek Szyprowski wrote:
On Friday, March 11, 2011 3:08 PM Arnd Bergmann wrote:
On Friday 11 March 2011, Marek Szyprowski wrote:
The iommu API is not really meant to be KVM specific, it's just that the
in-tree users are basically limited to KVM at the moment
On Friday 04 March 2011, Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- the new version introduces an api to construct device private page
tables and enables to use device private
701 - 753 of 753 matches
Mail list logo
