On 16 March 2012 10:43, Saugata Das wrote:
> On 16 March 2012 09:19, Girish K S wrote:
>> On 14 March 2012 20:53, Ulf Hansson wrote:
>>> Hi Girish and Chris,
>>>
>>> I noticed that this has been pushed for 3.3, I think we need to make a
>>> revert of it asap if possible.
>>>
>>> I were unfortuna
On 16 March 2012 10:43, Saugata Das wrote:
> On 16 March 2012 09:19, Girish K S wrote:
>> On 14 March 2012 20:53, Ulf Hansson wrote:
>>> Hi Girish and Chris,
>>>
>>> I noticed that this has been pushed for 3.3, I think we need to make a
>>> revert of it asap if possible.
>>>
>>> I were unfortuna
On 16 March 2012 09:19, Girish K S wrote:
> On 14 March 2012 20:53, Ulf Hansson wrote:
>> Hi Girish and Chris,
>>
>> I noticed that this has been pushed for 3.3, I think we need to make a
>> revert of it asap if possible.
>>
>> I were unfortunately not able to review this patch earlier but it has
On 14 March 2012 20:53, Ulf Hansson wrote:
> Hi Girish and Chris,
>
> I noticed that this has been pushed for 3.3, I think we need to make a
> revert of it asap if possible.
>
> I were unfortunately not able to review this patch earlier but it has issues
> I believe. It will break suspend/resume f
Hi Marek,
On Fri, Mar 09 2012, Marek Szyprowski wrote:
> exynos4_sdhci_drv_data structure is not available on non-Exynos builds,
> that's why EXYNOS4_SDHCI_DRV_DATA macro has been introduced. This patch
> fixes commit 67819656 'mmc: sdhci-s3c: Add device tree support' to use
> that macro. This fix
> -Original Message-
> From: Darius Augulis [mailto:augulis.dar...@gmail.com]
> Sent: Thursday, March 15, 2012 5:27 PM
> To: Jingoo Han
> Cc: Thomas Abraham; linux-fb...@vger.kernel.org; florianschandi...@gmx.de;
> linux-arm-
> ker...@lists.infradead.org; linux-samsung-soc@vger.kernel.or
On Thursday 15 March 2012, Kukjin Kim wrote:
> Hi Arnd, Olof,
>
> Please pull EXYNOS5250 gpio for v3.4.
>
>git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> next/soc-exynos5250-gpio
>
> It is including add support GPIOlib for EXYNOS5250 and Grant Likely
> already agre
On 15.03.2012 13:56, Mark Brown wrote:
> On Thu, Mar 15, 2012 at 11:04:56AM +0100, Karol Lewandowski wrote:
>
>> Introducing separate type (TYPE_S3C2440_HDMIPHY) has been our original
>> attempt to solve this issue. However, this required adding explicit
>> checks to driver code all over the pla
On 03/15/12 04:12, Joerg Roedel wrote:
On Thu, Mar 15, 2012 at 05:32:39PM +0900, Cho KyongHo wrote:
KyongHo, I looked at 'Cho KyongHo ' and 'KyongHo Cho
' in this series, which one do you want to use?
Handling System MMUs with an identifier is not flexible to manage
System MMU platform devi
Hi Arnd, Olof,
Please pull EXYNOS5250 gpio for v3.4.
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next/soc-exynos5250-gpio
It is including add support GPIOlib for EXYNOS5250 and Grant Likely
already agreed to send this via arm-soc for v3.4. Actually, this is
neede
On Wed, 14 Mar 2012 16:52:14 +, Mark Brown
wrote:
> Commit 054ebc (spi: Compatibility with direction which is used in samsung
> DMA operation) does not build as one hunk adds a brace to the first branch
> of an if statement without adding at least the correspoding close. Remove
> the unwanted
Hi Arnd, Olof,
Thank you for kindly review for EXYNOS5 and addressed comments.
Here are 'pull request' for supporting EXYNOS5250.
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next/soc-exynos5250-arch
It is based on next/devel-samsung-dma which has
On Thu, Mar 15, 2012 at 11:04:56AM +0100, Karol Lewandowski wrote:
> Introducing separate type (TYPE_S3C2440_HDMIPHY) has been our original
> attempt to solve this issue. However, this required adding explicit
> checks to driver code all over the place (if (type == S3C2400 ||
> type == S3c2440_HD
On Thu, Mar 15, 2012 at 05:32:39PM +0900, Cho KyongHo wrote:
> Handling System MMUs with an identifier is not flexible to manage
> System MMU platform devices because of the following reasons:
> 1. A device driver which needs to handle System MMU must know the ID.
> 2. A System MMU may not present
On 14.03.2012 18:29, Mark Brown wrote:
> On Tue, Mar 13, 2012 at 05:54:38PM +0100, Karol Lewandowski wrote:
>
>> - replace s3c24xx_i2c_type enum with plain unsigned int that can
>>hold not only device type but also hw revision-specific quirks
>
> Would it not be clearer to just have explici
This patch adds hsotg device to the GONI board.
Signed-off-by: Lukasz Majewski
Signed-off-by: Kyungmin Park
---
arch/arm/mach-s5pv210/Kconfig |1 +
arch/arm/mach-s5pv210/mach-goni.c |6 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconf
> -Original Message-
> From: Darius Augulis [mailto:augulis.dar...@gmail.com]
> Sent: Thursday, March 15, 2012 5:27 PM
> To: Jingoo Han
> Cc: Thomas Abraham; linux-fb...@vger.kernel.org; florianschandi...@gmx.de;
> linux-arm-
> ker...@lists.infradead.org; linux-samsung-soc@vger.kernel.or
Handling System MMUs with an identifier is not flexible to manage
System MMU platform devices because of the following reasons:
1. A device driver which needs to handle System MMU must know the ID.
2. A System MMU may not present in some implementations of Exynos family.
3. Handling System MMU with
This is the System MMU driver and IOMMU API implementation for
Exynos SOC platforms. Exynos platforms has more than 10 System
MMUs dedicated for each multimedia accelerators.
The System MMU driver is already in arc/arm/plat-s5p but it is
moved to drivers/iommu due to Ohad Ben-Cohen gathered IOMMU
This patch removes System MMU device driver from arm/plat-s5p tree
for transition to implement IOMMU driver.
Although controlling System MMU in this removing driver
is similar to the new IOMMU driver in the following patch,
the new one is almost rewrite of this driver and there is no
benefit to mov
These patches are successfully compiled in
linux-samsung.git/for-next branch
You can find the git repo in
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git
Changes since v11:
- Removed struct iommu_client and merged it
with struct sysmmu_drvdata
- Fix kfree() invalid address in
On Thu, Mar 15, 2012 at 10:10 AM, Jingoo Han wrote:
>> There is single board - mini6410 (or real6410) and it's name doesn't
>> depend on connected LCD size.
>> We know, that this board is available with different sizes of LCD and
>> currently we have in kernel support for both sizes.
>> It might
> -Original Message-
> From: Darius Augulis [mailto:augulis.dar...@gmail.com]
> Sent: Thursday, March 15, 2012 4:42 PM
> To: Jingoo Han
> Cc: Thomas Abraham; linux-fb...@vger.kernel.org; florianschandi...@gmx.de;
> linux-arm-
> ker...@lists.infradead.org; linux-samsung-soc@vger.kernel.or
Hi,
>
> Yes, only single LCD resolution will be left.
>
>> I have mini6410 with both 4.3" and 7" LCDs and real6410 with 7" LCD. Now
>> we have possibility to choose LCD size dynamically - leave it there.
>> What you mean "default" 4.3" size LCD? The 7" size LCD is also provided
>> by board sellers
24 matches
Mail list logo
