On 8/9/19 9:55 PM, Arnd Bergmann wrote:
> On Fri, Aug 9, 2019 at 4:36 PM Bartlomiej Zolnierkiewicz
> wrote:
>> On 8/9/19 1:43 PM, Arnd Bergmann wrote:
>
>>>
>>> That would have been ok as well, but having the addition here was
>>> intentional and seems more logical to me as this is where the
On Fri, Aug 9, 2019 at 4:36 PM Bartlomiej Zolnierkiewicz
wrote:
> On 8/9/19 1:43 PM, Arnd Bergmann wrote:
> >
> > That would have been ok as well, but having the addition here was
> > intentional and seems more logical to me as this is where the headers
> > get moved around.
> I see that this is
On 8/9/19 1:43 PM, Arnd Bergmann wrote:
> On Fri, Aug 9, 2019 at 1:32 PM Bartlomiej Zolnierkiewicz
> wrote:
>> On 8/8/19 11:22 PM, Arnd Bergmann wrote:
>>> The omapfb driver is split into platform specific code for omap1, and
>>> driver code that is also specific to omap1.
>>>
>>> Moving both
On Fri, Aug 9, 2019 at 1:32 PM Bartlomiej Zolnierkiewicz
wrote:
> On 8/8/19 11:22 PM, Arnd Bergmann wrote:
> > The omapfb driver is split into platform specific code for omap1, and
> > driver code that is also specific to omap1.
> >
> > Moving both parts into the driver directory simplifies the
On 8/8/19 11:22 PM, Arnd Bergmann wrote:
> The omapfb driver is split into platform specific code for omap1, and
> driver code that is also specific to omap1.
>
> Moving both parts into the driver directory simplifies the structure
> and avoids the dependency on certain omap machine header
The omapfb driver is split into platform specific code for omap1, and
driver code that is also specific to omap1.
Moving both parts into the driver directory simplifies the structure
and avoids the dependency on certain omap machine header files.
The interrupt numbers in particular however must
