On 2013-03-19 08:45, Archit Taneja wrote:
> I was trying to come up with a macro which could add default ops to the
> omap_dss_driver. It isn't straight forward as I thought, because you
> need to choose either the default op, or the panel driver's op if it
> exists. For example, I can't create a
On 2013-03-19 08:45, Archit Taneja wrote:
> I was trying to come up with a macro which could add default ops to the
> omap_dss_driver. It isn't straight forward as I thought, because you
> need to choose either the default op, or the panel driver's op if it
> exists. For example, I can't create a
On Tuesday 12 March 2013 08:23 PM, Tomi Valkeinen wrote:
> On 2013-03-12 16:38, Archit Taneja wrote:
>
>>> memcmp on two structs is often not a good idea. There could be padding
>>> bytes there, with uninitialized data. I'm not sure if that's the case
>>> here, though, but it could well change any
On Tuesday 12 March 2013 08:23 PM, Tomi Valkeinen wrote:
On 2013-03-12 16:38, Archit Taneja wrote:
memcmp on two structs is often not a good idea. There could be padding
bytes there, with uninitialized data. I'm not sure if that's the case
here, though, but it could well change any time (perhap
On Tuesday 12 March 2013 07:36 PM, Tomi Valkeinen wrote:
> On 2013-03-12 15:06, Archit Taneja wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI,
>> DSI
>> and SDI drivers. At some plac
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
On 2013-03-12 16:38, Archit Taneja wrote:
>> memcmp on two structs is often not a good idea. There could be padding
>> bytes there, with uninitialized data. I'm not sure if that's the case
>> here, though, but it could well change any time (perhaps even depending
>> on compiler version).
>
> I sa
On 2013-03-12 15:06, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
> has these
On 2013-03-12 16:38, Archit Taneja wrote:
>> memcmp on two structs is often not a good idea. There could be padding
>> bytes there, with uninitialized data. I'm not sure if that's the case
>> here, though, but it could well change any time (perhaps even depending
>> on compiler version).
>
> I sa
On 2013-03-12 15:06, Archit Taneja wrote:
> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
> and SDI drivers. At some places, there are no checks to see if the panel
> driver
> has these
On Tuesday 12 March 2013 07:36 PM, Tomi Valkeinen wrote:
On 2013-03-12 15:06, Archit Taneja wrote:
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there ar
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following
12 matches
Mail list logo
