Re: [PATCH] iommu/arm-smmu-v3: Handle duplicated Stream IDs from other masters
On Tue, Jan 12, 2021 at 12:57 AM Robin Murphy wrote: > > On 2021-01-07 13:03, Will Deacon wrote: > > On Thu, Jan 07, 2021 at 03:03:40PM +0530, Ajay Kumar wrote: > >> When PCI function drivers(ex:pci-endpoint-test) are probed for already > >> initialized PCIe-RC(Root Complex), and PCIe-RC is already bound to SMMU, > >> then we encounter a situation where the function driver tries to attach > >> itself to the smmu with the same stream-id as PCIe-RC and re-initialize > >> an already initialized STE. This causes ste_live BUG_ON() in the driver. > > Note that this is actually expected behaviour, since Stream ID aliasing > has remained officially not supported until a sufficiently compelling > reason to do so appears. I always thought the most likely scenario would > be a legacy PCI bridge with multiple devices behind it, but even that > seems increasingly improbable for a modern SMMUv3-based system to ever see. Thanks to Will and Robin for reviewing this. I am pretty new to PCI, sorry about that. I assumed that the support for stream-id alias is already handled as part of this patch: https://www.spinics.net/lists/arm-kernel/msg626087.html which prevents STE re-initialization. But, what I do not understand is why the path taken by the arm-smmu-v3 driver misses the aforementioned check for my usecase. > > I don't understand why the endpoint is using the same stream ID as the root > > complex in this case. Why is that? Is the grouping logic not working > > properly? > > It's not so much that it isn't working properly, it's more that it needs > to be implemented at all ;) The pci_endpoint_test picks up the same of_ DMA config node as the PCI RC because they sit on the same PCI bus [via pci_dma_configure( )] While in the arm-smmu-v3 driver, I can see that the pci_device_group( ) hands over the same iommu group as the Root Complex to the newly added master device (pci_endpoint_test in our case) because they share the same stream ID. Shouldn't they? > >> There is an already existing check in the driver to manage duplicated ids > >> if duplicated ids are added in same master device, but there can be > >> scenarios like above where we need to extend the check for other masters > >> using the same stream-id. > >> > >> Signed-off-by: Ajay Kumar > >> --- > >> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 33 + > >> 1 file changed, 33 insertions(+) > > > > It doesn't feel like the driver is the right place to fix this, as the same > > issue could surely occur for other IOMMUs too, right? In which case, I think > > we should avoid getting into the situation where different groups have > > overlapping stream IDs. > > Yes, this patch does not represent the correct thing to do either way. > The main reason that Stream ID aliasing hasn't been supported so far is > that the required Stream ID to group lookup is rather awkward, and > adding all of that complexity just for the sake of a rather unlikely > possibility seemed dubious. However, PRI support has always had a more > pressing need to implement almost the same thing (Stream ID to device), > so once that lands we can finally get round to adding the rest of proper > group support relatively easily. I hope the support will be added soon. Also, can you point me to few drivers which already handle this type of stream-ID aliasing? Thanks, Ajay Kumar > __ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/arm-smmu-v3: Handle duplicated Stream IDs from other masters
When PCI function drivers(ex:pci-endpoint-test) are probed for already
initialized PCIe-RC(Root Complex), and PCIe-RC is already bound to SMMU,
then we encounter a situation where the function driver tries to attach
itself to the smmu with the same stream-id as PCIe-RC and re-initialize
an already initialized STE. This causes ste_live BUG_ON() in the driver.
There is an already existing check in the driver to manage duplicated ids
if duplicated ids are added in same master device, but there can be
scenarios like above where we need to extend the check for other masters
using the same stream-id.
Signed-off-by: Ajay Kumar
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index e634bbe60573..a91c3c0e9ee8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2022,10 +2022,26 @@ static __le64 *arm_smmu_get_step_for_sid(struct
arm_smmu_device *smmu, u32 sid)
return step;
}
+static bool arm_smmu_check_duplicated_sid(struct arm_smmu_master *master,
+ int sid)
+{
+ int i;
+
+ for (i = 0; i < master->num_sids; ++i)
+ if (master->sids[i] == sid)
+ return true;
+
+ return false;
+}
+
static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
{
+ bool sid_in_other_masters;
int i, j;
struct arm_smmu_device *smmu = master->smmu;
+ unsigned long flags;
+ struct arm_smmu_domain *smmu_domain = master->domain;
+ struct arm_smmu_master *other_masters;
for (i = 0; i < master->num_sids; ++i) {
u32 sid = master->sids[i];
@@ -2038,6 +2054,23 @@ static void arm_smmu_install_ste_for_dev(struct
arm_smmu_master *master)
if (j < i)
continue;
+ /* Check for stream-ID duplication in masters in given domain */
+ sid_in_other_masters = false;
+ spin_lock_irqsave(_domain->devices_lock, flags);
+ list_for_each_entry(other_masters, _domain->devices,
+ domain_head) {
+ sid_in_other_masters =
+ arm_smmu_check_duplicated_sid(other_masters,
+ sid);
+ if (sid_in_other_masters)
+ break;
+ }
+ spin_unlock_irqrestore(_domain->devices_lock, flags);
+
+ /* Skip STE re-init if stream-id found in other masters */
+ if (sid_in_other_masters)
+ continue;
+
arm_smmu_write_strtab_ent(master, sid, step);
}
}
--
2.17.1
[RFC V2 PATCH] dma-iommu: allow devices to set IOVA range dynamically
Currently, there is no other option to change the lower limit of
IOVA for any device than calling iova_init_domain(), but the
said function will re-init whole domain and also doesn't track
the previously allocated IOVA before re-initing the domain.
There are cases where the device might not support continuous
range of addresses, and can also have dependency among buffers
allocated for firmware, image manipulation, etc and all of the
address requests pass through IOMMU. In such cases, we can allocate
buffers stage by stage by setting address limit, and also keep
track the of same.
Bit of background can be found here:
IOVA allocation dependency between firmware buffer and remaining buffers
https://www.spinics.net/lists/iommu/msg43586.html
This patch allows devices to limit the IOVA space they want
during allocation at any given point of time. We shall allow
the same only if the device owns the corresponding iommu_domain,
that is the device is the only master attached to the domain.
The lower limit of IOVA space is marked by start_pfn, and the upper
limit is marked by dma_mask and this patch honors the same.
Since changing dma_mask can extend the addressable region beyond
current cached node, we do a reset of current cached nodes as well.
User drivers can make call sequence like below:
When they want to limit IOVA for allocated buffers in range
0x0 to 0x100:
iommu_set_iova_range(dev, 0x0, 0x100 - 1);
When they want to limit IOVA for allocated buffers in range
0x100 to 0xC000:
iommu_set_iova_range(dev, 0x100, 0xC000 - 0x100);
=
Signed-off-by: Ajay Kumar
---
drivers/iommu/dma-iommu.c | 73 +++
drivers/iommu/iommu.c | 16 +
include/linux/iommu.h | 6
include/linux/iova.h | 6
4 files changed, 101 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 4959f5df21bd..2fe3f57ab648 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -167,6 +167,79 @@ void iommu_dma_get_resv_regions(struct device *dev, struct
list_head *list)
}
EXPORT_SYMBOL(iommu_dma_get_resv_regions);
+/**
+ * iommu_set_iova_range - Limit the IOVA region for a specific device
+ * @dev: Device to set IOVA range for
+ * @base: Base address or the lower limit of the IOVA range
+ * @size: Size of address range from lower limit to upper limit
+ *
+ * Allow a master device to dynamically control the range of IOVA addresses
+ * which are allocated iff the master device is the only device attached to
+ * the corresponding iommu_domain.
+ * This function doesn't harm IOVA addresses outside of current range,
+ * which were allocated prior to calling this function.
+ */
+int iommu_set_iova_range(struct device *dev, dma_addr_t base, u64 size)
+{
+ struct iommu_domain *domain;
+ struct iommu_dma_cookie *cookie;
+ struct iova_domain *iovad;
+ unsigned long shift, base_pfn;
+ u64 new_dma_mask;
+
+ /*
+* Check if the IOMMU master device is the sole entry in the group
+* If the group has more than one master device using the same IOMMU
+* we shouldn't be allowing that device to change the IOVA limit
+*/
+ if (iommu_group_device_count_from_dev(dev) != 1)
+ return -EINVAL;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (!domain)
+ return -ENODEV;
+
+ if (domain->type != IOMMU_DOMAIN_DMA)
+ return -EINVAL;
+
+ cookie = domain->iova_cookie;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -ENODEV;
+
+ iovad = >iovad;
+
+ shift = iova_shift(iovad);
+ base_pfn = base >> shift;
+
+ base_pfn = max_t(unsigned long, 1, base_pfn);
+
+ /* base cannot be outside aperture */
+ if (domain->geometry.force_aperture) {
+ if (base > domain->geometry.aperture_end ||
+ base + size <= domain->geometry.aperture_start) {
+ pr_warn("specified DMA range outside IOMMU
capability\n");
+ return -EFAULT;
+ }
+ /* ...then finally give it a kicking to make sure it fits */
+ base_pfn = max_t(unsigned long, base_pfn,
+ domain->geometry.aperture_start >> shift);
+ }
+ /* Set page aligned lower limit of IOVA range to start_pfn */
+ iovad->start_pfn = base_pfn;
+
+ /* Set upper limit of IOVA range to dma_mask */
+ new_dma_mask = (u64)base + size;
+ dma_set_mask_and_coherent(dev, new_dma_mask);
+
+ /* Reset cached nodes to start IOVA search from the anchor node */
+ iovad->cached_node = >anchor.node;
+ iovad->cached32_node = >anchor.node;
+
[RFC PATCH] dma-iommu: allow devices to set IOVA range dynamically
Currently, there is no other option to change the lower limit of
IOVA for any device than calling iova_init_domain(), but the
said function will re-init whole domain and also doesn't track
the previously allocated IOVA before re-initing the domain.
There are cases where the device might not support continuous
range of addresses, and can also have dependency among buffers
allocated for firmware, image manipulation, etc and all of the
address requests pass through IOMMU. In such cases, we can allocate
buffers stage by stage by setting address limit, and also keep
track the of same.
Bit of background can be found here:
IOVA allocation dependency between firmware buffer and remaining buffers
https://www.spinics.net/lists/iommu/msg43586.html
This patch allows devices to limit the IOVA space they want
during allocation at any given point of time. We shall allow
the same only if the device owns the corresponding iommu_domain,
that is the device is the only master attached to the domain.
The lower limit of IOVA space is marked by start_pfn, and the upper
limit is marked by dma_mask and this patch honors the same.
Since changing dma_mask can extend the addressable region beyond
current cached node, we do a reset of current cached nodes as well.
Signed-off-by: Ajay Kumar
---
drivers/iommu/dma-iommu.c | 73 +++
drivers/iommu/iommu.c | 16 +
include/linux/iommu.h | 6
include/linux/iova.h | 6
4 files changed, 101 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 4959f5df21bd..2fe3f57ab648 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -167,6 +167,79 @@ void iommu_dma_get_resv_regions(struct device *dev, struct
list_head *list)
}
EXPORT_SYMBOL(iommu_dma_get_resv_regions);
+/**
+ * iommu_set_iova_range - Limit the IOVA region for a specific device
+ * @dev: Device to set IOVA range for
+ * @base: Base address or the lower limit of the IOVA range
+ * @size: Size of address range from lower limit to upper limit
+ *
+ * Allow a master device to dynamically control the range of IOVA addresses
+ * which are allocated iff the master device is the only device attached to
+ * the corresponding iommu_domain.
+ * This function doesn't harm IOVA addresses outside of current range,
+ * which were allocated prior to calling this function.
+ */
+int iommu_set_iova_range(struct device *dev, dma_addr_t base, u64 size)
+{
+ struct iommu_domain *domain;
+ struct iommu_dma_cookie *cookie;
+ struct iova_domain *iovad;
+ unsigned long shift, base_pfn;
+ u64 new_dma_mask;
+
+ /*
+* Check if the IOMMU master device is the sole entry in the group
+* If the group has more than one master device using the same IOMMU
+* we shouldn't be allowing that device to change the IOVA limit
+*/
+ if (iommu_group_device_count_from_dev(dev) != 1)
+ return -EINVAL;
+
+ domain = iommu_get_domain_for_dev(dev);
+ if (!domain)
+ return -ENODEV;
+
+ if (domain->type != IOMMU_DOMAIN_DMA)
+ return -EINVAL;
+
+ cookie = domain->iova_cookie;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -ENODEV;
+
+ iovad = >iovad;
+
+ shift = iova_shift(iovad);
+ base_pfn = base >> shift;
+
+ base_pfn = max_t(unsigned long, 1, base_pfn);
+
+ /* base cannot be outside aperture */
+ if (domain->geometry.force_aperture) {
+ if (base > domain->geometry.aperture_end ||
+ base + size <= domain->geometry.aperture_start) {
+ pr_warn("specified DMA range outside IOMMU
capability\n");
+ return -EFAULT;
+ }
+ /* ...then finally give it a kicking to make sure it fits */
+ base_pfn = max_t(unsigned long, base_pfn,
+ domain->geometry.aperture_start >> shift);
+ }
+ /* Set page aligned lower limit of IOVA range to start_pfn */
+ iovad->start_pfn = base_pfn;
+
+ /* Set upper limit of IOVA range to dma_mask */
+ new_dma_mask = (u64)base + size;
+ dma_set_mask_and_coherent(dev, new_dma_mask);
+
+ /* Reset cached nodes to start IOVA search from the anchor node */
+ iovad->cached_node = >anchor.node;
+ iovad->cached32_node = >anchor.node;
+ iovad->max32_alloc_size = iovad->dma_32bit_pfn;
+
+ return 0;
+}
+EXPORT_SYMBOL(iommu_set_iova_range);
+
static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
phys_addr_t start, phys_addr_t end)
{
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 609bd25bf154..30b2d4e5487d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -919,6 +919,22 @@ static int iommu_gro
Re: [PATCH] iommu/iova: Retry from last rb tree node if iova search fails
On 5/7/20, Robin Murphy wrote:
> On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote:
>> From: Vijayanand Jitta
>>
>> When ever a new iova alloc request comes iova is always searched
>> from the cached node and the nodes which are previous to cached
>> node. So, even if there is free iova space available in the nodes
>> which are next to the cached node iova allocation can still fail
>> because of this approach.
>>
>> Consider the following sequence of iova alloc and frees on
>> 1GB of iova space
>>
>> 1) alloc - 500MB
>> 2) alloc - 12MB
>> 3) alloc - 499MB
>> 4) free - 12MB which was allocated in step 2
>> 5) alloc - 13MB
>>
>> After the above sequence we will have 12MB of free iova space and
>> cached node will be pointing to the iova pfn of last alloc of 13MB
>> which will be the lowest iova pfn of that iova space. Now if we get an
>> alloc request of 2MB we just search from cached node and then look
>> for lower iova pfn's for free iova and as they aren't any, iova alloc
>> fails though there is 12MB of free iova space.
>
> Yup, this could definitely do with improving. Unfortunately I think this
> particular implementation is slightly flawed...
>
>> To avoid such iova search failures do a retry from the last rb tree node
>> when iova search fails, this will search the entire tree and get an iova
>> if its available
>>
>> Signed-off-by: Vijayanand Jitta
>> ---
>> drivers/iommu/iova.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
>> index 0e6a953..2985222 100644
>> --- a/drivers/iommu/iova.c
>> +++ b/drivers/iommu/iova.c
>> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> unsigned long flags;
>> unsigned long new_pfn;
>> unsigned long align_mask = ~0UL;
>> +bool retry = false;
>>
>> if (size_aligned)
>> align_mask <<= fls_long(size - 1);
>> @@ -198,6 +199,8 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>>
>> curr = __get_cached_rbnode(iovad, limit_pfn);
>> curr_iova = rb_entry(curr, struct iova, node);
>> +
>> +retry_search:
>> do {
>> limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
>> new_pfn = (limit_pfn - size) & align_mask;
>> @@ -207,6 +210,14 @@ static int __alloc_and_insert_iova_range(struct
>> iova_domain *iovad,
>> } while (curr && new_pfn <= curr_iova->pfn_hi);
>>
>> if (limit_pfn < size || new_pfn < iovad->start_pfn) {
>> +if (!retry) {
>> +curr = rb_last(>rbroot);
>
> Why walk when there's an anchor node there already? However...
+1
>
>> +curr_iova = rb_entry(curr, struct iova, node);
>> +limit_pfn = curr_iova->pfn_lo;
>
> ...this doesn't look right, as by now we've lost the original limit_pfn
> supplied by the caller, so are highly likely to allocate beyond the
> range our caller asked for. In fact AFAICS we'd start allocating from
> directly directly below the anchor node, beyond the end of the entire
> address space.
+1
>
> The logic I was imagining we want here was something like the rapidly
> hacked up (and untested) diff below.
>
> Thanks,
> Robin.
>
> ->8-
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index 0e6a9536eca6..3574c19272d6 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -186,6 +186,7 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> unsigned long flags;
> unsigned long new_pfn;
> unsigned long align_mask = ~0UL;
> + unsigned long alloc_hi, alloc_lo;
>
> if (size_aligned)
> align_mask <<= fls_long(size - 1);
> @@ -196,17 +197,27 @@ static int __alloc_and_insert_iova_range(struct
> iova_domain *iovad,
> size >= iovad->max32_alloc_size)
> goto iova32_full;
>
> + alloc_hi = IOVA_ANCHOR;
> + alloc_lo = iovad->start_pfn;
> +retry:
> curr = __get_cached_rbnode(iovad, limit_pfn);
> curr_iova = rb_entry(curr, struct iova, node);
> + if (alloc_hi < curr_iova->pfn_hi) {
> + alloc_lo = curr_iova->pfn_hi;
> + alloc_hi = limit_pfn;
> + }
> +
> do {
> - limit_pfn = min(limit_pfn, curr_iova->pfn_lo);
> - new_pfn = (limit_pfn - size) & align_mask;
> + alloc_hi = min(alloc_hi, curr_iova->pfn_lo);
During retry case, the curr and curr_iova is not updated. Kindly check it.
Ajay
> + new_pfn = (alloc_hi - size) & align_mask;
> prev = curr;
> curr = rb_prev(curr);
> curr_iova = rb_entry(curr, struct iova, node);
> } while (curr && new_pfn <= curr_iova->pfn_hi);
>
> - if (limit_pfn < size || new_pfn < iovad->start_pfn) {
> + if (limit_pfn < size || new_pfn < alloc_lo) {
> + if (alloc_lo == iovad->start_pfn)
>
Re: Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel
Hi Sakari,
On Sat, Jun 3, 2017 at 1:48 PM, Sakari Ailus <sakari.ai...@iki.fi> wrote:
> Hi Ajay,
>
> On Fri, Jun 02, 2017 at 06:38:53PM +0530, Ajay kumar wrote:
>> Hi all,
>>
>> I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h,
>> media-bus-format.h and drm_fourcc.h
>> I could only find RGB 10BPC support in drm_fourcc.h.
>> I guess not much support is present for formats with (BPC > 8) in the kernel.
>
> What's "BPC"? Most YUV and RGB formats have only 8 bits per sample. More
> format definitions may be added if there's a driver that makes use of them.
BPC : Bits Per Color/Component
In my project, we have an image capture device which can capture 10 or
12 bits for each of R, G, B colors, i.e:
R[0:9] G[0:9] B[0:9] and
R[0:11] G[0:11] B[0:11]
I want to define macros for the above formats in videodev2.h.
But, I am not getting the logic behind the naming convention used to
define v4l2_fourcc macros.
ex:
V4L2_PIX_FMT_ARGB32 v4l2_fourcc('A', 'R', '2', '4');
How did they choose the characters 'A', 'R', '2', '4' in the above case?
I want to know the logic/naming convention behind that, so that I can create
new v4l2_fourcc defines for 10, 12 BPC formats and use in my driver.
Thanks,
Ajay Kumar
>>
>> Are there any plans to add fourcc defines for such formats?
>> Also, I wanted to how to define fourcc code for those formats?
>
> --
> Regards,
>
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel
Hi Sakari,
On Sat, Jun 3, 2017 at 1:48 PM, Sakari Ailus wrote:
> Hi Ajay,
>
> On Fri, Jun 02, 2017 at 06:38:53PM +0530, Ajay kumar wrote:
>> Hi all,
>>
>> I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h,
>> media-bus-format.h and drm_fourcc.h
>> I could only find RGB 10BPC support in drm_fourcc.h.
>> I guess not much support is present for formats with (BPC > 8) in the kernel.
>
> What's "BPC"? Most YUV and RGB formats have only 8 bits per sample. More
> format definitions may be added if there's a driver that makes use of them.
BPC : Bits Per Color/Component
In my project, we have an image capture device which can capture 10 or
12 bits for each of R, G, B colors, i.e:
R[0:9] G[0:9] B[0:9] and
R[0:11] G[0:11] B[0:11]
I want to define macros for the above formats in videodev2.h.
But, I am not getting the logic behind the naming convention used to
define v4l2_fourcc macros.
ex:
V4L2_PIX_FMT_ARGB32 v4l2_fourcc('A', 'R', '2', '4');
How did they choose the characters 'A', 'R', '2', '4' in the above case?
I want to know the logic/naming convention behind that, so that I can create
new v4l2_fourcc defines for 10, 12 BPC formats and use in my driver.
Thanks,
Ajay Kumar
>>
>> Are there any plans to add fourcc defines for such formats?
>> Also, I wanted to how to define fourcc code for those formats?
>
> --
> Regards,
>
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel
Hi all, I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h, media-bus-format.h and drm_fourcc.h I could only find RGB 10BPC support in drm_fourcc.h. I guess not much support is present for formats with (BPC > 8) in the kernel. Are there any plans to add fourcc defines for such formats? Also, I wanted to how to define fourcc code for those formats? Thanks, Ajay Kumar
Support for RGB/YUV 10, 12 BPC(bits per color/component) image data formats in kernel
Hi all, I have tried searching for RGB/YUV 10, 12 BPC formats in videodev2.h, media-bus-format.h and drm_fourcc.h I could only find RGB 10BPC support in drm_fourcc.h. I guess not much support is present for formats with (BPC > 8) in the kernel. Are there any plans to add fourcc defines for such formats? Also, I wanted to how to define fourcc code for those formats? Thanks, Ajay Kumar
Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup
On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam wrote: > Ajay, > > > On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar wrote: >> Hi, >> >> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam >> wrote: >>> These patches are based on 'for-next' branch of kgene's linux-samsung tree. >>> >>> Refactoring the exynos-dp-video phy to use pmu-system-controller handle >>> and access the register using mfd-syscon and regmap. >>> Simultaneously, removing the support for older dptx-phy, since it's obsolete >>> now and noone uses it. >>> >>> Vivek Gautam (3): >>> phy: exynos-dp-video: Use syscon support to control pmu register >>> drm/exynos: dp: Remove support for unused dptx-phy >>> arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy >>> >>> .../devicetree/bindings/phy/samsung-phy.txt|7 +- >>> arch/arm/boot/dts/exynos5250.dtsi |2 +- >>> arch/arm/boot/dts/exynos5420.dtsi |4 +- >>> drivers/gpu/drm/exynos/exynos_dp_core.c| 58 --- >>> drivers/gpu/drm/exynos/exynos_dp_core.h|2 - >>> drivers/phy/phy-exynos-dp-video.c | 76 >>> ++-- >>> 6 files changed, 75 insertions(+), 74 deletions(-) >>> >>> -- >>> 1.7.10.4 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-samsung-soc" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> I have tested this patchset on exynos5800-peach-pi, and I can see DP >> display with the above patches. > > we expect "Tested-by", if you have tested please give the same. Tested-by: Ajay Kumar Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup
Hi, On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam wrote: > These patches are based on 'for-next' branch of kgene's linux-samsung tree. > > Refactoring the exynos-dp-video phy to use pmu-system-controller handle > and access the register using mfd-syscon and regmap. > Simultaneously, removing the support for older dptx-phy, since it's obsolete > now and noone uses it. > > Vivek Gautam (3): > phy: exynos-dp-video: Use syscon support to control pmu register > drm/exynos: dp: Remove support for unused dptx-phy > arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy > > .../devicetree/bindings/phy/samsung-phy.txt|7 +- > arch/arm/boot/dts/exynos5250.dtsi |2 +- > arch/arm/boot/dts/exynos5420.dtsi |4 +- > drivers/gpu/drm/exynos/exynos_dp_core.c| 58 --- > drivers/gpu/drm/exynos/exynos_dp_core.h|2 - > drivers/phy/phy-exynos-dp-video.c | 76 > ++-- > 6 files changed, 75 insertions(+), 74 deletions(-) > > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I have tested this patchset on exynos5800-peach-pi, and I can see DP display with the above patches. Ajay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup
Hi, On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com wrote: These patches are based on 'for-next' branch of kgene's linux-samsung tree. Refactoring the exynos-dp-video phy to use pmu-system-controller handle and access the register using mfd-syscon and regmap. Simultaneously, removing the support for older dptx-phy, since it's obsolete now and noone uses it. Vivek Gautam (3): phy: exynos-dp-video: Use syscon support to control pmu register drm/exynos: dp: Remove support for unused dptx-phy arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy .../devicetree/bindings/phy/samsung-phy.txt|7 +- arch/arm/boot/dts/exynos5250.dtsi |2 +- arch/arm/boot/dts/exynos5420.dtsi |4 +- drivers/gpu/drm/exynos/exynos_dp_core.c| 58 --- drivers/gpu/drm/exynos/exynos_dp_core.h|2 - drivers/phy/phy-exynos-dp-video.c | 76 ++-- 6 files changed, 75 insertions(+), 74 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I have tested this patchset on exynos5800-peach-pi, and I can see DP display with the above patches. Ajay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup
On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam gautam.vi...@samsung.com wrote: Ajay, On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar ajayn...@gmail.com wrote: Hi, On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam gautam.vi...@samsung.com wrote: These patches are based on 'for-next' branch of kgene's linux-samsung tree. Refactoring the exynos-dp-video phy to use pmu-system-controller handle and access the register using mfd-syscon and regmap. Simultaneously, removing the support for older dptx-phy, since it's obsolete now and noone uses it. Vivek Gautam (3): phy: exynos-dp-video: Use syscon support to control pmu register drm/exynos: dp: Remove support for unused dptx-phy arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy .../devicetree/bindings/phy/samsung-phy.txt|7 +- arch/arm/boot/dts/exynos5250.dtsi |2 +- arch/arm/boot/dts/exynos5420.dtsi |4 +- drivers/gpu/drm/exynos/exynos_dp_core.c| 58 --- drivers/gpu/drm/exynos/exynos_dp_core.h|2 - drivers/phy/phy-exynos-dp-video.c | 76 ++-- 6 files changed, 75 insertions(+), 74 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I have tested this patchset on exynos5800-peach-pi, and I can see DP display with the above patches. we expect Tested-by, if you have tested please give the same. Tested-by: Ajay Kumar ajaykumar...@samsung.com Ajay -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/exynos: remove ifdeferry from initialization code
On Wed, Oct 1, 2014 at 11:18 AM, Inki Dae wrote:
> On 2014년 09월 30일 20:29, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Gently ping.
>
> Hi Andrzej,
>
> I merged it to local repository to test. But now exynos drm doesn't work
> correctly since pulling drm-next of Dave regardless of your patch.
>
> Problems are,
> 1. error occurs when we try to test modetest with -v option from second
> times.
I face a similar issue. For me, modetest -v doesn't work for the first try also.
I tried to test on snow and peach_pit.
modetest returns with following error from drm_crtc.c:
if (crtc->primary->fb->pixel_format != fb->pixel_format) {
DRM_DEBUG_KMS("Page flip is not allowed to change
frame buffer format.\n");
ret = -EINVAL;
goto out;
}
This has started coming since 3.15 I think.
Ajay
> 2. error occurs when we try to test unbind.
>
> Now we are checking these problems. Can you try to also check it?
>
> Thanks,
> Inki Dae
>
>>
>> Andrzej
>>
>> On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
>>> The patch replaces separate calls to driver (de)registration by
>>> loops over the array of drivers. As a result it significantly
>>> decreases number of ifdefs. Additionally it moves device registration
>>> related ifdefs to header file.
>>>
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> Hi Inki,
>>>
>>> During testing your component match support patch [1] I have prepared patch
>>> removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but
>>> I can rebase it if necessary.
>>>
>>> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031
>>>
>>> Regards
>>> Andrzej
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 170
>>> +++-
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++--
>>> 2 files changed, 48 insertions(+), 147 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index b2c710a..a660e46 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -553,74 +553,54 @@ static const struct component_master_ops
>>> exynos_drm_ops = {
>>> .unbind = exynos_drm_unbind,
>>> };
>>>
>>> -static int exynos_drm_platform_probe(struct platform_device *pdev)
>>> -{
>>> -struct component_match *match;
>>> -int ret;
>>> -
>>> -pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>> -exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>>> -
>>> +static struct platform_driver * const exynos_drm_drivers[] = {
>>> #ifdef CONFIG_DRM_EXYNOS_FIMD
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -return ret;
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_DP
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_fimd_drv;
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_DSI
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_dp_drv;
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_HDMI
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_dsi_drv;
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_mixer_drv;
>>> +_driver,
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_G2D
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_hdmi_drv;
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_FIMC
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_g2d_drv;
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_ROTATOR
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_fimc_drv;
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_GSC
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_rotator_drv;
>>> +_driver,
>>> #endif
>>> -
>>> #ifdef CONFIG_DRM_EXYNOS_IPP
>>> -ret = platform_driver_register(_driver);
>>> -if (ret < 0)
>>> -goto err_unregister_gsc_drv;
>>> +_driver,
>>> +#endif
>>> +};
>>> +
>>> +static int exynos_drm_platform_probe(struct platform_device *pdev)
>>> +{
>>> +struct component_match *match;
>>> +int ret, i;
>>> +
>>> +pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>>> +exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
>>> +
>>> +for (i = 0; i < ARRAY_SIZE(exynos_drm_drivers); ++i) {
>>> +ret = platform_driver_register(exynos_drm_drivers[i]);
>>> +if (ret < 0)
>>> +goto err_unregister_drivers;
>>> +}
>>>
>>> ret = exynos_platform_device_ipp_register();
>>>
Re: [PATCH] drm/exynos: remove ifdeferry from initialization code
On Wed, Oct 1, 2014 at 11:18 AM, Inki Dae inki@samsung.com wrote:
On 2014년 09월 30일 20:29, Andrzej Hajda wrote:
Hi Inki,
Gently ping.
Hi Andrzej,
I merged it to local repository to test. But now exynos drm doesn't work
correctly since pulling drm-next of Dave regardless of your patch.
Problems are,
1. error occurs when we try to test modetest with -v option from second
times.
I face a similar issue. For me, modetest -v doesn't work for the first try also.
I tried to test on snow and peach_pit.
modetest returns with following error from drm_crtc.c:
if (crtc-primary-fb-pixel_format != fb-pixel_format) {
DRM_DEBUG_KMS(Page flip is not allowed to change
frame buffer format.\n);
ret = -EINVAL;
goto out;
}
This has started coming since 3.15 I think.
Ajay
2. error occurs when we try to test unbind.
Now we are checking these problems. Can you try to also check it?
Thanks,
Inki Dae
Andrzej
On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
The patch replaces separate calls to driver (de)registration by
loops over the array of drivers. As a result it significantly
decreases number of ifdefs. Additionally it moves device registration
related ifdefs to header file.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
---
Hi Inki,
During testing your component match support patch [1] I have prepared patch
removing most ifdefs from exynos_drm_drv.c. It is based on your patch, but
I can rebase it if necessary.
[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/37031
Regards
Andrzej
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 170
+++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 25 +++--
2 files changed, 48 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b2c710a..a660e46 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -553,74 +553,54 @@ static const struct component_master_ops
exynos_drm_ops = {
.unbind = exynos_drm_unbind,
};
-static int exynos_drm_platform_probe(struct platform_device *pdev)
-{
-struct component_match *match;
-int ret;
-
-pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
-exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
-
+static struct platform_driver * const exynos_drm_drivers[] = {
#ifdef CONFIG_DRM_EXYNOS_FIMD
-ret = platform_driver_register(fimd_driver);
-if (ret 0)
-return ret;
+fimd_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_DP
-ret = platform_driver_register(dp_driver);
-if (ret 0)
-goto err_unregister_fimd_drv;
+dp_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_DSI
-ret = platform_driver_register(dsi_driver);
-if (ret 0)
-goto err_unregister_dp_drv;
+dsi_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_HDMI
-ret = platform_driver_register(mixer_driver);
-if (ret 0)
-goto err_unregister_dsi_drv;
-ret = platform_driver_register(hdmi_driver);
-if (ret 0)
-goto err_unregister_mixer_drv;
+mixer_driver,
+hdmi_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_G2D
-ret = platform_driver_register(g2d_driver);
-if (ret 0)
-goto err_unregister_hdmi_drv;
+g2d_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_FIMC
-ret = platform_driver_register(fimc_driver);
-if (ret 0)
-goto err_unregister_g2d_drv;
+fimc_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_ROTATOR
-ret = platform_driver_register(rotator_driver);
-if (ret 0)
-goto err_unregister_fimc_drv;
+rotator_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_GSC
-ret = platform_driver_register(gsc_driver);
-if (ret 0)
-goto err_unregister_rotator_drv;
+gsc_driver,
#endif
-
#ifdef CONFIG_DRM_EXYNOS_IPP
-ret = platform_driver_register(ipp_driver);
-if (ret 0)
-goto err_unregister_gsc_drv;
+ipp_driver,
+#endif
+};
+
+static int exynos_drm_platform_probe(struct platform_device *pdev)
+{
+struct component_match *match;
+int ret, i;
+
+pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
+
+for (i = 0; i ARRAY_SIZE(exynos_drm_drivers); ++i) {
+ret = platform_driver_register(exynos_drm_drivers[i]);
+if (ret 0)
+goto err_unregister_drivers;
+}
ret = exynos_platform_device_ipp_register();
if (ret 0)
-goto err_unregister_ipp_drv;
-#endif
+goto err_unregister_drivers;
match = exynos_drm_match_add(pdev-dev);
if (IS_ERR(match)) {
@@ -632,96 +612,24 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
Re: [PATCH 1/1] ARM: exynos_defconfig: Enable options for display panel support
Hi, On Wed, Sep 3, 2014 at 9:56 PM, Kukjin Kim wrote: > Javier Martinez Canillas wrote: >> >> Many Exynos devices have a display panel, most of them just have >> a simple panel while others have more complex configurations that >> requires an embedded DisplayPort (eDP) to LVDS display bridge. >> >> This patch enables the following features to support both setups: >> >> - Direct Rendering Manager (DRM) >> - DRM bridge registration and lookup framework >> - Parade ps8622/ps8625 eDP/LVDS bridge >> - NXP ptn3460 eDP/LVDS bridge >> - Exynos Fully Interactive Mobile Display controller (FIMD) >> - Panel registration and lookup framework >> - Simple panels >> - Backlight and LCD device support >> > Thanks a lot. > > >> Signed-off-by: Javier Martinez Canillas >> --- >> >> Some of the options enabled here (e.g: the eDP/LVDS bridges) >> are still not merged in mainline so this patch depends on >> the following posted patches that were still not merged: >> >> "drm/bridge: Modify drm_bridge core to support driver model" [0] >> "drm/bridge: Add i2c based driver for ptn3460 bridge" [1] >> "drm/bridge: Add i2c based driver for ps8622/ps8625 bridge" [2] >> > BTW, I can't find its re-spin...how was going on? I already sent this a week back.Find it here: http://www.spinics.net/lists/dri-devel/msg66740.html Inki Dae, In this patchset, patch "[PATCH V7 5/12] drm/exynos: dp: support drm_bridge" introduces following Kconfig error: drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:39: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:33: symbol DRM_KMS_HELPER is selected by DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_EXYNOS_DP drivers/gpu/drm/exynos/Kconfig:53: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD drivers/gpu/drm/exynos/Kconfig:28: symbol DRM_EXYNOS_FIMD depends on FB_S3C drivers/video/fbdev/Kconfig:2038: symbol FB_S3C depends on FB How to fix this? Can we remove dependency between FB_S3C and DRM_EXYNOS_FIMD? >> But I wanted to post anyways to make easier for others to >> figure out what are the needed options to have the display >> working on their Exynos machines. >> >> In order to test the display panel on the Peach machines, >> the following patches are also needed: >> >> "ARM: dts: Add DT changes for display on peach_pit" [3] >> "ARM: dts: Add DT changes for display on peach_pi" [4] >> > I'll have a look them soon. The above ones are older versions. Latest ones are here: 1) http://www.spinics.net/lists/linux-samsung-soc/msg35344.html 2) http://www.spinics.net/lists/arm-kernel/msg358324.html 3) http://www.spinics.net/lists/arm-kernel/msg358325.html Among the above, patch (1) can be merged because corresponding driver changes are already merged! Ajay > - Kukjin > >> Best regards, >> Javier >> >> [0]: http://patchwork.ozlabs.org/patch/373792/ >> [1]: http://patchwork.ozlabs.org/patch/373793/ >> [2]: http://patchwork.ozlabs.org/patch/373794/ >> [3]: http://www.spinics.net/lists/arm-kernel/msg350568.html >> [4]: http://www.spinics.net/lists/arm-kernel/msg350569.html >> >> arch/arm/configs/exynos_defconfig | 14 ++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/arch/arm/configs/exynos_defconfig >> b/arch/arm/configs/exynos_defconfig >> index 676c744..f69d57e 100644 >> --- a/arch/arm/configs/exynos_defconfig >> +++ b/arch/arm/configs/exynos_defconfig >> @@ -101,11 +101,25 @@ CONFIG_REGULATOR_S2MPA01=y >> CONFIG_REGULATOR_S2MPS11=y >> CONFIG_REGULATOR_S5M8767=y >> CONFIG_REGULATOR_TPS65090=y >> +CONFIG_DRM=y >> +CONFIG_DRM_BRIDGE=y >> +CONFIG_DRM_PS8622=y >> +CONFIG_DRM_EXYNOS=y >> +CONFIG_DRM_EXYNOS_FIMD=y >> +CONFIG_DRM_EXYNOS_DP=y >> +CONFIG_DRM_PANEL=y >> +CONFIG_DRM_PANEL_SIMPLE=y >> CONFIG_FB=y >> CONFIG_FB_MODE_HELPERS=y >> CONFIG_FB_SIMPLE=y >> CONFIG_EXYNOS_VIDEO=y >> CONFIG_EXYNOS_MIPI_DSI=y >> +CONFIG_BACKLIGHT_LCD_SUPPORT=y >> +CONFIG_LCD_CLASS_DEVICE=y >> +CONFIG_LCD_PLATFORM=y >> +CONFIG_BACKLIGHT_CLASS_DEVICE=y >> +CONFIG_BACKLIGHT_GENERIC=y >> +CONFIG_BACKLIGHT_PWM=y >> CONFIG_FRAMEBUFFER_CONSOLE=y >> CONFIG_FONTS=y >> CONFIG_FONT_7x14=y >> -- >> 2.0.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: exynos_defconfig: Enable options for display panel support
Hi, On Wed, Sep 3, 2014 at 9:56 PM, Kukjin Kim kgene@samsung.com wrote: Javier Martinez Canillas wrote: Many Exynos devices have a display panel, most of them just have a simple panel while others have more complex configurations that requires an embedded DisplayPort (eDP) to LVDS display bridge. This patch enables the following features to support both setups: - Direct Rendering Manager (DRM) - DRM bridge registration and lookup framework - Parade ps8622/ps8625 eDP/LVDS bridge - NXP ptn3460 eDP/LVDS bridge - Exynos Fully Interactive Mobile Display controller (FIMD) - Panel registration and lookup framework - Simple panels - Backlight and LCD device support Thanks a lot. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Some of the options enabled here (e.g: the eDP/LVDS bridges) are still not merged in mainline so this patch depends on the following posted patches that were still not merged: drm/bridge: Modify drm_bridge core to support driver model [0] drm/bridge: Add i2c based driver for ptn3460 bridge [1] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge [2] BTW, I can't find its re-spin...how was going on? I already sent this a week back.Find it here: http://www.spinics.net/lists/dri-devel/msg66740.html Inki Dae, In this patchset, patch [PATCH V7 5/12] drm/exynos: dp: support drm_bridge introduces following Kconfig error: drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:39: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:33: symbol DRM_KMS_HELPER is selected by DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_EXYNOS_DP drivers/gpu/drm/exynos/Kconfig:53: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD drivers/gpu/drm/exynos/Kconfig:28: symbol DRM_EXYNOS_FIMD depends on FB_S3C drivers/video/fbdev/Kconfig:2038: symbol FB_S3C depends on FB How to fix this? Can we remove dependency between FB_S3C and DRM_EXYNOS_FIMD? But I wanted to post anyways to make easier for others to figure out what are the needed options to have the display working on their Exynos machines. In order to test the display panel on the Peach machines, the following patches are also needed: ARM: dts: Add DT changes for display on peach_pit [3] ARM: dts: Add DT changes for display on peach_pi [4] I'll have a look them soon. The above ones are older versions. Latest ones are here: 1) http://www.spinics.net/lists/linux-samsung-soc/msg35344.html 2) http://www.spinics.net/lists/arm-kernel/msg358324.html 3) http://www.spinics.net/lists/arm-kernel/msg358325.html Among the above, patch (1) can be merged because corresponding driver changes are already merged! Ajay - Kukjin Best regards, Javier [0]: http://patchwork.ozlabs.org/patch/373792/ [1]: http://patchwork.ozlabs.org/patch/373793/ [2]: http://patchwork.ozlabs.org/patch/373794/ [3]: http://www.spinics.net/lists/arm-kernel/msg350568.html [4]: http://www.spinics.net/lists/arm-kernel/msg350569.html arch/arm/configs/exynos_defconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 676c744..f69d57e 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -101,11 +101,25 @@ CONFIG_REGULATOR_S2MPA01=y CONFIG_REGULATOR_S2MPS11=y CONFIG_REGULATOR_S5M8767=y CONFIG_REGULATOR_TPS65090=y +CONFIG_DRM=y +CONFIG_DRM_BRIDGE=y +CONFIG_DRM_PS8622=y +CONFIG_DRM_EXYNOS=y +CONFIG_DRM_EXYNOS_FIMD=y +CONFIG_DRM_EXYNOS_DP=y +CONFIG_DRM_PANEL=y +CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_SIMPLE=y CONFIG_EXYNOS_VIDEO=y CONFIG_EXYNOS_MIPI_DSI=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +CONFIG_LCD_PLATFORM=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_BACKLIGHT_GENERIC=y +CONFIG_BACKLIGHT_PWM=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FONTS=y CONFIG_FONT_7x14=y -- 2.0.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot
Hi Thierry, Thanks for adding me. On Thu, Jul 31, 2014 at 5:26 PM, Thierry Reding wrote: > Cc'ing Ajay (who raised this on a different thread recently), therefore > quoting all of the original email. > > Thierry > > On Thu, Jul 31, 2014 at 01:42:50PM +0200, Thierry Reding wrote: >> From: Thierry Reding >> >> The default for backlight devices is to be enabled immediately when >> registering with the backlight core. This can be useful for setups that >> use a simple framebuffer device and where the backlight cannot otherwise >> be hooked up to the panel. >> >> However, when dealing with more complex setups, such as those of recent >> ARM SoCs, this can be problematic. Since the backlight is usually setup >> separately from the display controller, the probe order is not usually >> deterministic. That can lead to situations where the backlight will be >> powered up and the panel will show an uninitialized framebuffer. >> >> Furthermore, subsystems such as DRM have advanced functionality to set >> the power mode of a panel. In order to allow such setups to power up the >> panel at exactly the right moment, a way is needed to prevent the >> backlight core from powering the backlight up automatically when it is >> registered. >> >> This commit introduces a new boot_off field in the platform data (and >> also implements getting the same information from device tree). When set >> the initial backlight power mode will be set to "off". >> >> Signed-off-by: Thierry Reding >> --- >> I've been meaning to send this for a while but was always holding back >> because of the indoctrination that this type of configuration shouldn't >> be part of device tree. However this issue was recently raised again in >> the context of power up sequences for display panels. As described above >> the issue is that panel datasheets recommend that the backlight attached >> to a panel be turned on at the very last step to avoid visual glitches >> during the panel's power up sequence. With the current implementation it >> is typical for the backlight to be probed before the display panel. That >> has, in many cases, the side-effect of enabling the backlight, therefore >> making the screen content visible before it's actually initialized. >> >> Some panels come up with random garbage when uninitialized, others show >> all white. With some luck the panel will be all black and users won't >> really notice. Right, most of the DSI panels are lucky. But the case is not the same with few eDP/LVDS panels. >> This patch is an attempt to enable boards to override the default of >> turning on the backlight for the pwm-backlight driver. I'm not sure if >> there was a specific reason to turn on the backlight by default when >> this driver was initially written, but the fact is that since it has >> pretty much always been like this we can't really go and change the >> default, otherwise a lot of people may end up with no backlight and no >> clue as to how to enable it. So the only reasonable thing we can do is >> to keep the old behaviour and give new boards a way to override it if >> they know that some other part of the stack will enable it at the right >> moment. Agreed! And, I have tested this patch. This resolves the only remaining problem for display on peach_pi. I cannot see the boot time glitch anymore :) Ajay >> .../devicetree/bindings/video/backlight/pwm-backlight.txt | 1 + >> drivers/video/backlight/pwm_bl.c | 8 >> >> include/linux/pwm_backlight.h | 2 ++ >> 3 files changed, 11 insertions(+) >> >> diff --git >> a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt >> b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt >> index 764db86d441a..65e001a1733d 100644 >> --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt >> +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt >> @@ -17,6 +17,7 @@ Optional properties: >> "pwms" property (see PWM binding[0]) >>- enable-gpios: contains a single GPIO specifier for the GPIO which >> enables >>and disables the backlight (see GPIO binding[1]) >> + - backlight-boot-off: keep the backlight disabled on boot >> >> [0]: Documentation/devicetree/bindings/pwm/pwm.txt >> [1]: Documentation/devicetree/bindings/gpio/gpio.txt >> diff --git a/drivers/video/backlight/pwm_bl.c >> b/drivers/video/backlight/pwm_bl.c >> index d7a3d13e72ec..62adfc9d37a7 100644 >> --- a/drivers/video/backlight/pwm_bl.c >> +++ b/drivers/video/backlight/pwm_bl.c >> @@ -173,6 +173,8 @@ static int pwm_backlight_parse_dt(struct device *dev, >> data->max_brightness--; >> } >> >> + data->boot_off = of_property_read_bool(node, "backlight-boot-off"); >> + >> return 0; >> } >> >> @@ -317,6 +319,12 @@ static int pwm_backlight_probe(struct platform_device >> *pdev) >> } >> >>
Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot
Hi Thierry, Thanks for adding me. On Thu, Jul 31, 2014 at 5:26 PM, Thierry Reding thierry.red...@gmail.com wrote: Cc'ing Ajay (who raised this on a different thread recently), therefore quoting all of the original email. Thierry On Thu, Jul 31, 2014 at 01:42:50PM +0200, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The default for backlight devices is to be enabled immediately when registering with the backlight core. This can be useful for setups that use a simple framebuffer device and where the backlight cannot otherwise be hooked up to the panel. However, when dealing with more complex setups, such as those of recent ARM SoCs, this can be problematic. Since the backlight is usually setup separately from the display controller, the probe order is not usually deterministic. That can lead to situations where the backlight will be powered up and the panel will show an uninitialized framebuffer. Furthermore, subsystems such as DRM have advanced functionality to set the power mode of a panel. In order to allow such setups to power up the panel at exactly the right moment, a way is needed to prevent the backlight core from powering the backlight up automatically when it is registered. This commit introduces a new boot_off field in the platform data (and also implements getting the same information from device tree). When set the initial backlight power mode will be set to off. Signed-off-by: Thierry Reding tred...@nvidia.com --- I've been meaning to send this for a while but was always holding back because of the indoctrination that this type of configuration shouldn't be part of device tree. However this issue was recently raised again in the context of power up sequences for display panels. As described above the issue is that panel datasheets recommend that the backlight attached to a panel be turned on at the very last step to avoid visual glitches during the panel's power up sequence. With the current implementation it is typical for the backlight to be probed before the display panel. That has, in many cases, the side-effect of enabling the backlight, therefore making the screen content visible before it's actually initialized. Some panels come up with random garbage when uninitialized, others show all white. With some luck the panel will be all black and users won't really notice. Right, most of the DSI panels are lucky. But the case is not the same with few eDP/LVDS panels. This patch is an attempt to enable boards to override the default of turning on the backlight for the pwm-backlight driver. I'm not sure if there was a specific reason to turn on the backlight by default when this driver was initially written, but the fact is that since it has pretty much always been like this we can't really go and change the default, otherwise a lot of people may end up with no backlight and no clue as to how to enable it. So the only reasonable thing we can do is to keep the old behaviour and give new boards a way to override it if they know that some other part of the stack will enable it at the right moment. Agreed! And, I have tested this patch. This resolves the only remaining problem for display on peach_pi. I cannot see the boot time glitch anymore :) Ajay .../devicetree/bindings/video/backlight/pwm-backlight.txt | 1 + drivers/video/backlight/pwm_bl.c | 8 include/linux/pwm_backlight.h | 2 ++ 3 files changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt index 764db86d441a..65e001a1733d 100644 --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt @@ -17,6 +17,7 @@ Optional properties: pwms property (see PWM binding[0]) - enable-gpios: contains a single GPIO specifier for the GPIO which enables and disables the backlight (see GPIO binding[1]) + - backlight-boot-off: keep the backlight disabled on boot [0]: Documentation/devicetree/bindings/pwm/pwm.txt [1]: Documentation/devicetree/bindings/gpio/gpio.txt diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c index d7a3d13e72ec..62adfc9d37a7 100644 --- a/drivers/video/backlight/pwm_bl.c +++ b/drivers/video/backlight/pwm_bl.c @@ -173,6 +173,8 @@ static int pwm_backlight_parse_dt(struct device *dev, data-max_brightness--; } + data-boot_off = of_property_read_bool(node, backlight-boot-off); + return 0; } @@ -317,6 +319,12 @@ static int pwm_backlight_probe(struct platform_device *pdev) } bl-props.brightness = data-dft_brightness; + + if (data-boot_off) + bl-props.power = FB_BLANK_POWERDOWN; + else +
Re: [PATCH v3 4/4] ARM: dts: Add exynos5250-spring device tree
On Thu, Jul 31, 2014 at 3:23 PM, Andreas Färber wrote:
> Hi,
>
> Am 31.07.2014 11:49, schrieb Ajay kumar:
>> On Thu, Jul 31, 2014 at 2:56 PM, Andreas Färber wrote:
>>> Am 30.07.2014 15:50, schrieb Andreas Färber:
>>>> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
>>>> b/arch/arm/boot/dts/exynos5250-spring.dts
>>>> new file mode 100644
>>>> index ..bcca892bf2ff
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
>>> [...]
>>>> +_0 {
>>>> + dp_hpd_gpio: dp-hpd-gpio {
>>>> + samsung,pins = "gpc3-0";
>>>> + samsung,pin-function = <1>;
>>>
>>> Not sure where this 1 came from... Both Ajay and my 3.8 DT have 0.
>> Right, this should be 0.
>>
>>>> + samsung,pin-pud = <3>;
>>>> + samsung,pin-drv = <0>;
>>>> + };
>>>
>>> Seeing that Ajay called this node dp-hdp, it should probably be an override?
>> dp_hpd should be enough. I will keep the same name for peach boards.
>> dp_hpd: dp-hpd {
>> .
>> .
>> .
>> };
>
> Apart from my own set of typos, I see that you proposed dp-hpd whereas
> -pinctrl.dtsi has dp_hpd (dash vs. underscore). My question is, can we
> override the pinctrl one instead of adding a new one, or do they need to
> coexist?
The one in exynos5250-pinctrl.dtsi will be used only for smdk5250/snow.
For spring, you can override the same.
Ajay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] ARM: dts: Add exynos5250-spring device tree
Hi Andreas,
On Thu, Jul 31, 2014 at 2:56 PM, Andreas Färber wrote:
> Am 30.07.2014 15:50, schrieb Andreas Färber:
>> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
>> b/arch/arm/boot/dts/exynos5250-spring.dts
>> new file mode 100644
>> index ..bcca892bf2ff
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> [...]
>> +_0 {
>> + dp_hpd_gpio: dp-hpd-gpio {
>> + samsung,pins = "gpc3-0";
>> + samsung,pin-function = <1>;
>
> Not sure where this 1 came from... Both Ajay and my 3.8 DT have 0.
Right, this should be 0.
>> + samsung,pin-pud = <3>;
>> + samsung,pin-drv = <0>;
>> + };
>
> Seeing that Ajay called this node dp-hdp, it should probably be an override?
dp_hpd should be enough. I will keep the same name for peach boards.
dp_hpd: dp-hpd {
.
.
.
};
Ajay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] ARM: dts: Add exynos5250-spring device tree
Hi Andreas,
On Thu, Jul 31, 2014 at 2:56 PM, Andreas Färber afaer...@suse.de wrote:
Am 30.07.2014 15:50, schrieb Andreas Färber:
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index ..bcca892bf2ff
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
[...]
+pinctrl_0 {
+ dp_hpd_gpio: dp-hpd-gpio {
+ samsung,pins = gpc3-0;
+ samsung,pin-function = 1;
Not sure where this 1 came from... Both Ajay and my 3.8 DT have 0.
Right, this should be 0.
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
Seeing that Ajay called this node dp-hdp, it should probably be an override?
dp_hpd should be enough. I will keep the same name for peach boards.
dp_hpd: dp-hpd {
.
.
.
};
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] ARM: dts: Add exynos5250-spring device tree
On Thu, Jul 31, 2014 at 3:23 PM, Andreas Färber afaer...@suse.de wrote:
Hi,
Am 31.07.2014 11:49, schrieb Ajay kumar:
On Thu, Jul 31, 2014 at 2:56 PM, Andreas Färber afaer...@suse.de wrote:
Am 30.07.2014 15:50, schrieb Andreas Färber:
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index ..bcca892bf2ff
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
[...]
+pinctrl_0 {
+ dp_hpd_gpio: dp-hpd-gpio {
+ samsung,pins = gpc3-0;
+ samsung,pin-function = 1;
Not sure where this 1 came from... Both Ajay and my 3.8 DT have 0.
Right, this should be 0.
+ samsung,pin-pud = 3;
+ samsung,pin-drv = 0;
+ };
Seeing that Ajay called this node dp-hdp, it should probably be an override?
dp_hpd should be enough. I will keep the same name for peach boards.
dp_hpd: dp-hpd {
.
.
.
};
Apart from my own set of typos, I see that you proposed dp-hpd whereas
-pinctrl.dtsi has dp_hpd (dash vs. underscore). My question is, can we
override the pinctrl one instead of adding a new one, or do they need to
coexist?
The one in exynos5250-pinctrl.dtsi will be used only for smdk5250/snow.
For spring, you can override the same.
Ajay
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
> Signed-off-by: Kishon Vijay Abraham I
> ---
> Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
> drivers/usb/musb/omap2430.c| 55
>
> 2 files changed, 88 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 80a28c9..39cdffb 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -1,4 +1,4 @@
> -OMAP USB PHY
> +OMAP USB PHY AND GLUE
>
> OMAP USB2 PHY
>
> @@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
> compatible = "ti,omap-usb2";
> reg = <0x4a0ad080 0x58>;
> };
> +
> +OMAP MUSB GLUE
> + - compatible : Should be "ti,musb-omap2430"
> + - ti,hwmods : must be "usb_otg_hs"
> + - multipoint : Should be "1" indicating the musb controller supports
> + multipoint. This is a MUSB configuration-specific setting.
> + - num_eps : Specifies the number of endpoints. This is also a
> + MUSB configuration-specific setting. Should be set to "16"
> + - ram_bits : Specifies the ram address size. Should be set to "12"
> + - interface_type : This is a board specific setting to describe the type
> of
> + interface between the controller and the phy. It should be "0" or "1"
> + specifying ULPI and UTMI respectively.
> + - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
> + represents PERIPHERAL.
> + - power : Should be "50". This signifies the controller can supply upto
> + 100mA when operating in host mode.
> +
> +SOC specific device node entry
> +usb_otg_hs: usb_otg_hs@4a0ab000 {
> + compatible = "ti,musb-omap2430";
> + ti,hwmods = "usb_otg_hs";
> + multipoint = <1>;
> + num_eps = <16>;
> + ram_bits = <12>;
> +};
> +
> +Board specific device node entry
> +_otg_hs {
> + interface_type = <1>;
> + mode = <3>;
> + power = <50>;
> +};
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index addbebf..331e477 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
> static int __devinit omap2430_probe(struct platform_device *pdev)
> {
> struct musb_hdrc_platform_data *pdata = pdev->dev.platform_data;
> + struct omap_musb_board_data *data;
> struct platform_device *musb;
> struct omap2430_glue*glue;
> + struct device_node *np = pdev->dev.of_node;
> + struct musb_hdrc_config *config;
> struct resource *res;
> int ret = -ENOMEM;
>
> @@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct
> platform_device *pdev)
> if (glue->control_otghs == NULL)
> dev_dbg(>dev, "Failed to obtain control memory\n");
>
> + if (np) {
> + pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + dev_err(>dev,
> + "failed to allocate musb platfrom data\n");
> + ret = -ENOMEM;
> + goto err1;
> + }
> +
> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> + if (!data) {
> + dev_err(>dev,
> + "failed to allocate musb board data\n");
> + ret = -ENOMEM;
> + goto err1;
> + }
> +
> + config = devm_kzalloc(>dev, sizeof(*config), GFP_KERNEL);
> + if (!data) {
> + dev_err(>dev,
> + "failed to allocate musb hdrc config\n");
> + goto err1;
> + }
> +
> + of_property_read_u32(np, "mode", (u32 *)>mode);
> + of_property_read_u32(np, "interface_type",
> + (u32 *)>interface_type);
> + of_property_read_u32(np, "num_eps", (u32 *)>num_eps);
> + of_property_read_u32(np, "ram_bits", (u32 *)>ram_bits);
> + of_property_read_u32(np, "mode", (u32 *)>mode);
pdata->mode is already read so above should be removed.
Ajay
> + of_property_read_u32(np, "power", (u32 *)>power);
> + config->multipoint = of_property_read_bool(np, "multipoint");
> +
> + pdata->board_data = data;
> + pdata->config = config;
> + }
> +
> pdata->platform_ops = _ops;
>
> platform_set_drvdata(pdev, glue);
> @@ -597,12 +638,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
> #define DEV_PM_OPS NULL
> #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id omap2430_id_table[] = {
> + {
> +
RE: [PATCH v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type
of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
pdata-mode is already read so above should be removed.
Ajay
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +638,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+ .compatible =
RE: [PATCH v1 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
> Documentation/devicetree/bindings/usb/omap-usb.txt | 34
> -
> drivers/usb/musb/omap2430.c| 52
>
[...]
> + of_property_read_u32(np, "mode", (u32 *)>mode);
> + of_property_read_u32(np, "interface_type",
> + (u32 *)>interface_type);
> + of_property_read_u32(np, "num_eps", (u32 *)
> >num_eps);
> + of_property_read_u32(np, "ram_bits", (u32 *)
> >ram_bits);
> + of_property_read_u32(np, "mode", (u32 *)>mode);
'mode' has already been read so this should be dropped.
Ajay
> + of_property_read_u32(np, "power", (u32 *)>power);
> + config->multipoint = of_property_read_bool(np,
> "multipoint");
> +
> + pdata->board_data = data;
> + pdata->config = config;
> + }
> +
> pdata->platform_ops = _ops;
>
> platform_set_drvdata(pdev, glue);
> @@ -597,12 +638,23 @@ static struct dev_pm_ops omap2430_pm_ops = {
> #define DEV_PM_OPS NULL
> #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id omap2430_id_table[] = {
> + { .compatible = "ti,musb-omap2430" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, omap2430_id_table);
> +#else
> +#define omap2430_id_table NULL
> +#endif
> +
> static struct platform_driver omap2430_driver = {
> .probe = omap2430_probe,
> .remove = __devexit_p(omap2430_remove),
> .driver = {
> .name = "musb-omap2430",
> .pm = DEV_PM_OPS,
> + .of_match_table = omap2430_id_table,
> },
> };
>
> --
> 1.7.5.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v1 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
Documentation/devicetree/bindings/usb/omap-usb.txt | 34
-
drivers/usb/musb/omap2430.c| 52
[...]
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-
num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-
ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
'mode' has already been read so this should be dropped.
Ajay
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np,
multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +638,23 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ { .compatible = ti,musb-omap2430 },
+ {}
+};
+MODULE_DEVICE_TABLE(of, omap2430_id_table);
+#else
+#define omap2430_id_table NULL
+#endif
+
static struct platform_driver omap2430_driver = {
.probe = omap2430_probe,
.remove = __devexit_p(omap2430_remove),
.driver = {
.name = musb-omap2430,
.pm = DEV_PM_OPS,
+ .of_match_table = omap2430_id_table,
},
};
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
