Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1568922 > unrolled thread
| Started by | Peter Senna Tschudin <peter.senna@collabora.com> |
|---|---|
| First post | 2017-01-28 15:20 +0100 |
| Last post | 2017-01-30 18:10 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge Peter Senna Tschudin <peter.senna@collabora.com> - 2017-01-28 15:20 +0100
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge Jani Nikula <jani.nikula@linux.intel.com> - 2017-01-30 18:10 +0100
| From | Peter Senna Tschudin <peter.senna@collabora.com> |
|---|---|
| Date | 2017-01-28 15:20 +0100 |
| Subject | Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge |
| Message-ID | <t4C1b-2wu-11@gated-at.bofh.it> |
On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
Hi Archit,
Thank you for the comments!
[...]
> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
> > + if (total_size > EDID_LENGTH) {
> > + kfree(block);
> > + block = kmalloc(total_size, GFP_KERNEL);
> > + if (!block)
> > + return NULL;
> > +
> > + /* Yes, read the entire buffer, and do not skip the first
> > + * EDID_LENGTH bytes.
> > + */
>
> Is this the reason why you aren't using drm_do_get_edid()?
Yes, for some hw specific reason, it is necessary to read the entire
EDID buffer starting from 0, not block by block.
[...]
I fixed all your other suggestions. Thank you!
[toc] | [next] | [standalone]
| From | Jani Nikula <jani.nikula@linux.intel.com> |
|---|---|
| Date | 2017-01-30 18:10 +0100 |
| Subject | Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge |
| Message-ID | <t5nCN-6CL-9@gated-at.bofh.it> |
| In reply to | #1568922 |
On Sat, 28 Jan 2017, Peter Senna Tschudin <peter.senna@collabora.com> wrote:
> On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
> Hi Archit,
>
> Thank you for the comments!
>
> [...]
>> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
>> > + if (total_size > EDID_LENGTH) {
>> > + kfree(block);
>> > + block = kmalloc(total_size, GFP_KERNEL);
>> > + if (!block)
>> > + return NULL;
>> > +
>> > + /* Yes, read the entire buffer, and do not skip the first
>> > + * EDID_LENGTH bytes.
>> > + */
>>
>> Is this the reason why you aren't using drm_do_get_edid()?
>
> Yes, for some hw specific reason, it is necessary to read the entire
> EDID buffer starting from 0, not block by block.
Hrmh, I'm planning on moving the edid override and firmware edid
mechanisms at the drm_do_get_edid() level to be able to truly and
transparently use a different edid. Currently, they're only used for
modes, really, and lead to some info retrieved from overrides, some from
the real edid. This kind of hacks will bypass the override/firmware edid
mechanisms then too. :(
BR,
Jani.
>
> [...]
>
> I fixed all your other suggestions. Thank you!
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web