* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-26 23:18 [U-Boot] List of offending drivers Marek Vasut
@ 2012-07-27 1:08 ` Graeme Russ
2012-07-27 1:11 ` Marek Vasut
2012-07-27 4:41 ` Wolfgang Denk
` (2 subsequent siblings)
3 siblings, 1 reply; 18+ messages in thread
From: Graeme Russ @ 2012-07-27 1:08 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Fri, Jul 27, 2012 at 9:18 AM, Marek Vasut <marex@denx.de> wrote:
> Hello,
>
> Check the following list, it's the list of drivers scattered (misplaced) across
> the tree. The list is not complete and might be inaccurate. But it should give a
> good impression of what I'm going to break soon:
>
> arch/x86/cpu/sc520/sc520_pci.c
> board/eNET/eNET_pci.c
Hmm, I'm wondering what where the line between 'driver' and 'arch/board
specific driver glue' is? How was this list generated?
You seem to have missed sc520_ssi.c and sc520_timer.c
board/eNET/eNET_pci.c only contains:
pci_enet_fixup_irq() - Board specific configuration of PCI interrupt lines.
This is a platform function which is specified when the board initialises
the PCI driver. Note that this function calls pci_sc520_set_irq() which is
located on arch/x86/cpu/sc520/sc520_pci.c (see below)
pci_init_board() - One line wrapper for pci_sc520_init() which should get
dropped once the driver model and init sequence (if that gets looked at
again) refactoring
pci_set_regions() - Configure the board-specific PCI memory and I/O regions
arch/x86/cpu/sc520/sc520_pci.c contains:
pci_sc520_set_irq() - A support function for board-specific PCI interrupt
line configuration
pci_sc520_init() - SC520 specific PCI driver initialisation
So neither of these files are 'drivers' per-se. They are really just
initialisation and platform specific support functions. How do these fit
into the new driver model?
Regards,
Graeme
^ permalink raw reply [flat|nested] 18+ messages in thread* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 1:08 ` [U-Boot] [U-Boot-DM] " Graeme Russ
@ 2012-07-27 1:11 ` Marek Vasut
2012-07-27 1:20 ` Graeme Russ
0 siblings, 1 reply; 18+ messages in thread
From: Marek Vasut @ 2012-07-27 1:11 UTC (permalink / raw)
To: u-boot
Dear Graeme Russ,
> Hi Marek,
>
> On Fri, Jul 27, 2012 at 9:18 AM, Marek Vasut <marex@denx.de> wrote:
> > Hello,
> >
> > Check the following list, it's the list of drivers scattered (misplaced)
> > across the tree. The list is not complete and might be inaccurate. But
> > it should give a good impression of what I'm going to break soon:
> >
> > arch/x86/cpu/sc520/sc520_pci.c
> > board/eNET/eNET_pci.c
>
> Hmm, I'm wondering what where the line between 'driver' and 'arch/board
> specific driver glue' is?
That's why I said the list isn't exactly precise.
> How was this list generated?
By hard manual labor (=slavework).
> You seem to have missed sc520_ssi.c and sc520_timer.c
I wonder if we should move the timer drivers ... maybe to drivers/timer/ ?
> board/eNET/eNET_pci.c only contains:
>
> pci_enet_fixup_irq() - Board specific configuration of PCI interrupt lines.
> This is a platform function which is specified when the board initialises
> the PCI driver. Note that this function calls pci_sc520_set_irq() which is
> located on arch/x86/cpu/sc520/sc520_pci.c (see below)
Ok, so this one should be left out, I didn't properly examine them all. Just
wanted to share the list, the examination will follow this weekend, when I start
moving them.
> pci_init_board() - One line wrapper for pci_sc520_init() which should get
> dropped once the driver model and init sequence (if that gets looked at
> again) refactoring
>
> pci_set_regions() - Configure the board-specific PCI memory and I/O regions
>
> arch/x86/cpu/sc520/sc520_pci.c contains:
> pci_sc520_set_irq() - A support function for board-specific PCI interrupt
> line configuration
> pci_sc520_init() - SC520 specific PCI driver initialisation
>
> So neither of these files are 'drivers' per-se. They are really just
> initialisation and platform specific support functions. How do these fit
> into the new driver model?
You can supply a pointer to that function to some "pci" driver I guess ...
Pavel?
> Regards,
>
> Graeme
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 1:11 ` Marek Vasut
@ 2012-07-27 1:20 ` Graeme Russ
2012-07-27 1:26 ` Marek Vasut
0 siblings, 1 reply; 18+ messages in thread
From: Graeme Russ @ 2012-07-27 1:20 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Graeme Russ,
>
>> So neither of these files are 'drivers' per-se. They are really just
>> initialisation and platform specific support functions. How do these fit
>> into the new driver model?
>
> You can supply a pointer to that function to some "pci" driver I guess ...
> Pavel?
In which case you have a board/arch specific function to intialise the
pointer :) Hmm, or are we now looking at a variation of my INIT_FUNC
architecture where this gets done at compile time?
Regards,
Graeme
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 1:20 ` Graeme Russ
@ 2012-07-27 1:26 ` Marek Vasut
2012-07-27 1:29 ` Graeme Russ
0 siblings, 1 reply; 18+ messages in thread
From: Marek Vasut @ 2012-07-27 1:26 UTC (permalink / raw)
To: u-boot
Dear Graeme Russ,
> Hi Marek,
>
> On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Graeme Russ,
> >
> >> So neither of these files are 'drivers' per-se. They are really just
> >> initialisation and platform specific support functions. How do these fit
> >> into the new driver model?
> >
> > You can supply a pointer to that function to some "pci" driver I guess
> > ... Pavel?
>
> In which case you have a board/arch specific function to intialise the
> pointer :)
No, you have static platform data which contain the pointer.
> Hmm, or are we now looking at a variation of my INIT_FUNC
> architecture where this gets done at compile time?
I think you missed the point here
> Regards,
>
> Graeme
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 1:26 ` Marek Vasut
@ 2012-07-27 1:29 ` Graeme Russ
2012-07-27 1:37 ` Marek Vasut
0 siblings, 1 reply; 18+ messages in thread
From: Graeme Russ @ 2012-07-27 1:29 UTC (permalink / raw)
To: u-boot
Hi Marek,
On Fri, Jul 27, 2012 at 11:26 AM, Marek Vasut <marex@denx.de> wrote:
> Dear Graeme Russ,
>
>> Hi Marek,
>>
>> On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut <marex@denx.de> wrote:
>> > Dear Graeme Russ,
>> >
>> >> So neither of these files are 'drivers' per-se. They are really just
>> >> initialisation and platform specific support functions. How do these fit
>> >> into the new driver model?
>> >
>> > You can supply a pointer to that function to some "pci" driver I guess
>> > ... Pavel?
>>
>> In which case you have a board/arch specific function to intialise the
>> pointer :)
>
> No, you have static platform data which contain the pointer.
Ah, of course
>> Hmm, or are we now looking at a variation of my INIT_FUNC
>> architecture where this gets done at compile time?
>
> I think you missed the point here
Yes, by --->| |<--- that much :)
Oh, unless of course it has to be done dynamically due to a single U-Boot
image supporting multiple board hardware configurations...
Regards
Graeme
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 1:29 ` Graeme Russ
@ 2012-07-27 1:37 ` Marek Vasut
0 siblings, 0 replies; 18+ messages in thread
From: Marek Vasut @ 2012-07-27 1:37 UTC (permalink / raw)
To: u-boot
Dear Graeme Russ,
> Hi Marek,
>
> On Fri, Jul 27, 2012 at 11:26 AM, Marek Vasut <marex@denx.de> wrote:
> > Dear Graeme Russ,
> >
> >> Hi Marek,
> >>
> >> On Fri, Jul 27, 2012 at 11:11 AM, Marek Vasut <marex@denx.de> wrote:
> >> > Dear Graeme Russ,
> >> >
> >> >> So neither of these files are 'drivers' per-se. They are really just
> >> >> initialisation and platform specific support functions. How do these
> >> >> fit into the new driver model?
> >> >
> >> > You can supply a pointer to that function to some "pci" driver I guess
> >> > ... Pavel?
> >>
> >> In which case you have a board/arch specific function to intialise the
> >> pointer :)
> >
> > No, you have static platform data which contain the pointer.
>
> Ah, of course
>
> >> Hmm, or are we now looking at a variation of my INIT_FUNC
> >> architecture where this gets done at compile time?
> >
> > I think you missed the point here
>
> Yes, by --->| |<--- that much :)
>
> Oh, unless of course it has to be done dynamically due to a single U-Boot
> image supporting multiple board hardware configurations...
Which is not yet happening, let's take small steps, ok?
> Regards
>
> Graeme
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-26 23:18 [U-Boot] List of offending drivers Marek Vasut
2012-07-27 1:08 ` [U-Boot] [U-Boot-DM] " Graeme Russ
@ 2012-07-27 4:41 ` Wolfgang Denk
2012-07-27 8:42 ` Marek Vasut
2012-07-31 7:50 ` Mike Frysinger
2012-07-27 6:28 ` [U-Boot] " Lukasz Majewski
2012-08-01 10:11 ` [U-Boot] [U-Boot-DM] " Andreas Bießmann
3 siblings, 2 replies; 18+ messages in thread
From: Wolfgang Denk @ 2012-07-27 4:41 UTC (permalink / raw)
To: u-boot
Dear Marek Vasut,
In message <201207270118.19524.marex@denx.de> you wrote:
>
> Check the following list, it's the list of drivers scattered (misplaced) across
> the tree. The list is not complete and might be inaccurate. But it should give a
> good impression of what I'm going to break soon:
> board/BuS/EB+MCF-EV123/cfm_flash.c
> board/BuS/EB+MCF-EV123/flash.c
> board/LEOX/elpt860/flash.c
> board/Marvell/common/flash.c
> board/Marvell/common/intel_flash.c
> board/RPXClassic/flash.c
> board/RPXlite/flash.c
> board/RPXlite_dw/flash.c
> board/RRvision/flash.c
> board/a3000/flash.c
> board/alaska/flash.c
> board/altera/common/flash.c
> board/amcc/bamboo/flash.c
> board/amcc/bubinga/flash.c
> board/amcc/common/flash.c
> board/amcc/ebony/flash.c
> board/amcc/luan/flash.c
> board/amcc/ocotea/flash.c
> board/amcc/taihu/flash.c
> board/amcc/walnut/flash.c
> board/amcc/yucca/flash.c
> board/amirix/ap1000/flash.c
> board/atc/flash.c
> board/bct-brettl2/gpio_cfi_flash.c
> board/bf533-ezkit/flash.c
> board/bmw/flash.c
> board/c2mon/flash.c
> board/cm-bf527/gpio_cfi_flash.c
> board/cm-bf537e/gpio_cfi_flash.c
> board/cm-bf537u/gpio_cfi_flash.c
> board/cm4008/flash.c
> board/cm41xx/flash.c
> board/cmi/flash.c
> board/cobra5272/flash.c
> board/cogent/flash.c
> board/cpc45/flash.c
> board/cpu86/flash.c
> board/cpu87/flash.c
> board/cray/L1/flash.c
> board/cu824/flash.c
> board/dave/PPChameleonEVB/flash.c
> board/dave/common/flash.c
> board/earthlcd/favr-32-ezkit/flash.c
> board/eltec/elppc/flash.c
> board/eltec/mhpc/flash.c
> board/emk/common/flash.c
> board/ep8260/flash.c
> board/esd/adciop/flash.c
> board/esd/ar405/flash.c
> board/esd/ash405/flash.c
> board/esd/canbt/flash.c
> board/esd/cms700/flash.c
> board/esd/common/flash.c
> board/esd/cpci2dp/flash.c
> board/esd/cpci405/flash.c
> board/esd/cpci5200/strataflash.c
> board/esd/cpciiser4/flash.c
> board/esd/dasa_sim/flash.c
> board/esd/dp405/flash.c
> board/esd/du405/flash.c
> board/esd/hh405/flash.c
> board/esd/hub405/flash.c
> board/esd/ocrtc/flash.c
> board/esd/pci405/flash.c
> board/esd/pf5200/flash.c
> board/esd/plu405/flash.c
> board/esd/tasreg/flash.c
> board/esd/voh405/flash.c
> board/esd/vom405/flash.c
> board/esd/wuh405/flash.c
> board/esteem192e/flash.c
> board/etin/debris/flash.c
> board/etx094/flash.c
> board/evb64260/flash.c
> board/evb64260/intel_flash.c
> board/fads/flash.c
> board/flagadm/flash.c
> board/freescale/m5253demo/flash.c
> board/freescale/mpc8260ads/flash.c
> board/freescale/mpc8266ads/flash.c
> board/funkwerk/vovpn-gw/flash.c
> board/g2000/strataflash.c
> board/gen860t/flash.c
> board/genietv/flash.c
> board/gth2/flash.c
> board/gw8260/flash.c
> board/hermes/flash.c
> board/hidden_dragon/flash.c
> board/hymod/flash.c
> board/icecube/flash.c
> board/icu862/flash.c
> board/idmr/flash.c
> board/incaip/flash.c
> ard/ip860/flash.c
> board/iphase4539/flash.c
> board/ivm/flash.c
> board/jse/flash.c
> board/kup/common/flash.c
> board/lantec/flash.c
> board/lubbock/flash.c
> board/lwmon/flash.c
> board/mbx8xx/flash.c
> board/micronas/vct/ebi_nor_flash.c
> board/ml2/flash.c
> board/mousse/flash.c
> board/musenki/flash.c
> board/mvblue/flash.c
> board/mx1ads/syncflash.c
> board/netphone/flash.c
> board/netta/flash.c
> board/netta2/flash.c
> board/netvia/flash.c
> board/ns9750dev/flash.c
> board/nx823/flash.c
> board/o2dnt/flash.c
> board/pb1x00/flash.c
> board/pcippc2/flash.c
> board/pcs440ep/flash.c
> board/pm520/flash.c
> board/pm826/flash.c
> board/pm828/flash.c
> board/ppmc7xx/flash.c
> board/ppmc8260/strataflash.c
> board/prodrive/common/flash.c
> board/prodrive/pdnb3/flash.c
> board/r360mpi/flash.c
> board/rbc823/flash.c
> board/rpxsuper/flash.c
> board/rsdproto/flash.c
> board/sacsng/flash.c
> board/sandburst/common/flash.c
> board/sandpoint/flash.c
> board/sbc405/strataflash.c
> board/scb9328/flash.c
> board/siemens/IAD210/flash.c
> board/siemens/SCM/flash.c
> board/sixnet/flash.c
> board/snmc/qs850/flash.c
> board/snmc/qs860t/flash.c
> board/spd8xx/flash.c
> board/stx/stxgp3/flash.c
> board/svm_sc8xx/flash.c
> board/tcm-bf537/gpio_cfi_flash.c
> board/ti/omap730p2/flash.c
> board/tqc/tqm5200/cam5200_flash.c
> board/utx8245/flash.c
> board/v37/flash.c
> board/w7o/flash.c
> board/westel/amx860/flash.c
> board/xaeniax/flash.c
All these are either
1) old versions of flash drivers that predate the cfi flash
implementation, so they could be replaced by the CFI driver (if
there was someone to test this)
or
2) very special versions of flash drivers dealing with board specific
details that prevent the use of the CFI flash driver, in which case
they should remain in the board directories.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 4:41 ` Wolfgang Denk
@ 2012-07-27 8:42 ` Marek Vasut
2012-07-27 9:33 ` Wolfgang Denk
2012-07-31 7:50 ` Mike Frysinger
1 sibling, 1 reply; 18+ messages in thread
From: Marek Vasut @ 2012-07-27 8:42 UTC (permalink / raw)
To: u-boot
Dear Wolfgang Denk,
> Dear Marek Vasut,
>
> In message <201207270118.19524.marex@denx.de> you wrote:
> > Check the following list, it's the list of drivers scattered (misplaced)
> > across the tree. The list is not complete and might be inaccurate. But
> > it should give a good impression of what I'm going to break soon:
[...]
> All these are either
>
> 1) old versions of flash drivers that predate the cfi flash
> implementation, so they could be replaced by the CFI driver (if
> there was someone to test this)
Well, can they not be replaced either way? Someone will eventually complain if
they care enough.
> or
>
> 2) very special versions of flash drivers dealing with board specific
> details that prevent the use of the CFI flash driver, in which case
> they should remain in the board directories.
Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later
replaced with platform data) ?
> Best regards,
>
> Wolfgang Denk
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 8:42 ` Marek Vasut
@ 2012-07-27 9:33 ` Wolfgang Denk
0 siblings, 0 replies; 18+ messages in thread
From: Wolfgang Denk @ 2012-07-27 9:33 UTC (permalink / raw)
To: u-boot
Dear Marek Vasut,
In message <201207271042.48099.marex@denx.de> you wrote:
>
> > All these are either
> >
> > 1) old versions of flash drivers that predate the cfi flash
> > implementation, so they could be replaced by the CFI driver (if
> > there was someone to test this)
>
> Well, can they not be replaced either way? Someone will eventually complain if
> they care enough.
No. I will not accept moving reduindant crap into the drivers/
hierarchy. If this is code that can be replaced by using the CFI
driver, this reorganization is the point to do it.
If the boards are uinmaintained, then so be it, we will remove broken
stuff.
> > 2) very special versions of flash drivers dealing with board specific
> > details that prevent the use of the CFI flash driver, in which case
> > they should remain in the board directories.
>
> Can these not be unified (read stuffed with #ifdef-#endif blocks for now, later
> replaced with platform data) ?
I don't see how this could be done, and it seems not worth the effort
to me. I smell most of these are unmaintained boards, and it's easier
to clean this up once for all.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course there's no reason for it, it's just our policy.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-27 4:41 ` Wolfgang Denk
2012-07-27 8:42 ` Marek Vasut
@ 2012-07-31 7:50 ` Mike Frysinger
1 sibling, 0 replies; 18+ messages in thread
From: Mike Frysinger @ 2012-07-31 7:50 UTC (permalink / raw)
To: u-boot
On Friday 27 July 2012 00:41:45 Wolfgang Denk wrote:
> Marek Vasut wrote:
> > Check the following list, it's the list of drivers scattered (misplaced)
> > across the tree. The list is not complete and might be inaccurate. But
> > it should give a good impression of what I'm going to break soon:
> >
> > board/bf533-ezkit/flash.c
>
> 1) old versions of flash drivers that predate the cfi flash
> implementation, so they could be replaced by the CFI driver (if
> there was someone to test this)
yep. this driver is wicked old, and has since languished for a few reasons:
- the people who wrote it originally were (are) not exactly great
programmers. in fact, they were pretty terrible.
- this particular board is one of the first Blackfins to see a real open source
port, but the board itself isn't terribly developer friendly, so no one pays
too much attention to it.
- the flash does not support the CFI query command which means none of the
stock CFI code would work out of the box (it does use the AMD CFI commandset
though).
- the flash is funky -- it's two chips in a single package which leads to
quite a bit of confusion, and it also has SRAM areas on it !
- the Blackfin maintainers who took over weren't terribly familiar with the
CFI spec (i would say i only have a little familiarity at a higher level).
at any rate, i was able to figure out the JEDEC probe logic in Linux somewhat
recently to make it work there, and so i ported that to u-boot which means we
can drop this old driver (patches already posted). seems to
probe/read/erase/write just fine, so ship it ;).
> > board/bct-brettl2/gpio_cfi_flash.c
> > board/cm-bf527/gpio_cfi_flash.c
> > board/cm-bf537e/gpio_cfi_flash.c
> > board/cm-bf537u/gpio_cfi_flash.c
> > board/tcm-bf537/gpio_cfi_flash.c
>
> 2) very special versions of flash drivers dealing with board specific
> details that prevent the use of the CFI flash driver, in which case
> they should remain in the board directories.
yep. these are merely glue to support the flashes on these boards that use
GPIO's for additional address lines. they actually use the common CFI code
already.
there is a thread from a while ago discussing how to make these work better in
the larger u-boot framework (NOR flashes which are not fully directly mapped),
but i honestly don't think i'll ever get around to implementing that idea. i
have no job that requires it, and only had a passing interest in implementing
it ;).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120731/6d6cff13/attachment.pgp>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] List of offending drivers
2012-07-26 23:18 [U-Boot] List of offending drivers Marek Vasut
2012-07-27 1:08 ` [U-Boot] [U-Boot-DM] " Graeme Russ
2012-07-27 4:41 ` Wolfgang Denk
@ 2012-07-27 6:28 ` Lukasz Majewski
2012-07-27 8:43 ` Marek Vasut
2012-08-01 10:11 ` [U-Boot] [U-Boot-DM] " Andreas Bießmann
3 siblings, 1 reply; 18+ messages in thread
From: Lukasz Majewski @ 2012-07-27 6:28 UTC (permalink / raw)
To: u-boot
Dear Marek Vasut,
> board/samsung/goni/onenand.c
> board/samsung/smdkc100/onenand.c
> board/samsung/universal_c210/onenand.c
Those files aren't drivers. Those are board specific init functions and
in my opinion shall stay where they are.
--
Best regards,
Lukasz Majewski
Samsung Poland R&D Center | Linux Platform Group
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] List of offending drivers
2012-07-27 6:28 ` [U-Boot] " Lukasz Majewski
@ 2012-07-27 8:43 ` Marek Vasut
2012-07-27 14:11 ` Igor Grinberg
0 siblings, 1 reply; 18+ messages in thread
From: Marek Vasut @ 2012-07-27 8:43 UTC (permalink / raw)
To: u-boot
Dear Lukasz Majewski,
> Dear Marek Vasut,
>
> > board/samsung/goni/onenand.c
> > board/samsung/smdkc100/onenand.c
> > board/samsung/universal_c210/onenand.c
>
> Those files aren't drivers. Those are board specific init functions and
> in my opinion shall stay where they are.
That's fairy possible, I did only quick inspection and I'll be taking further
look this weekend.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] List of offending drivers
2012-07-27 8:43 ` Marek Vasut
@ 2012-07-27 14:11 ` Igor Grinberg
2012-07-27 14:30 ` Marek Vasut
0 siblings, 1 reply; 18+ messages in thread
From: Igor Grinberg @ 2012-07-27 14:11 UTC (permalink / raw)
To: u-boot
Hi Marek,
On 07/27/12 11:43, Marek Vasut wrote:
> Dear Lukasz Majewski,
>
>> Dear Marek Vasut,
>>
>>> board/samsung/goni/onenand.c
>>> board/samsung/smdkc100/onenand.c
>>> board/samsung/universal_c210/onenand.c
>>
>> Those files aren't drivers. Those are board specific init functions and
>> in my opinion shall stay where they are.
>
> That's fairy possible, I did only quick inspection and I'll be taking further
> look this weekend.
May be you should do a further look before sending a heads up about
everything you see...
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] List of offending drivers
2012-07-27 14:11 ` Igor Grinberg
@ 2012-07-27 14:30 ` Marek Vasut
2012-07-27 14:45 ` Igor Grinberg
0 siblings, 1 reply; 18+ messages in thread
From: Marek Vasut @ 2012-07-27 14:30 UTC (permalink / raw)
To: u-boot
Dear Igor Grinberg,
> Hi Marek,
>
> On 07/27/12 11:43, Marek Vasut wrote:
> > Dear Lukasz Majewski,
> >
> >> Dear Marek Vasut,
> >>
> >>> board/samsung/goni/onenand.c
> >>> board/samsung/smdkc100/onenand.c
> >>> board/samsung/universal_c210/onenand.c
> >>
> >> Those files aren't drivers. Those are board specific init functions and
> >> in my opinion shall stay where they are.
> >
> > That's fairy possible, I did only quick inspection and I'll be taking
> > further look this weekend.
>
> May be you should do a further look before sending a heads up about
> everything you see...
Where are you aiming with this exactly? I clearly stated I didn't do deep
inspection of these and that there might be mishits
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] List of offending drivers
2012-07-27 14:30 ` Marek Vasut
@ 2012-07-27 14:45 ` Igor Grinberg
2012-07-27 14:49 ` Marek Vasut
0 siblings, 1 reply; 18+ messages in thread
From: Igor Grinberg @ 2012-07-27 14:45 UTC (permalink / raw)
To: u-boot
On 07/27/12 17:30, Marek Vasut wrote:
> Dear Igor Grinberg,
>
>> Hi Marek,
>>
>> On 07/27/12 11:43, Marek Vasut wrote:
>>> Dear Lukasz Majewski,
>>>
>>>> Dear Marek Vasut,
>>>>
>>>>> board/samsung/goni/onenand.c
>>>>> board/samsung/smdkc100/onenand.c
>>>>> board/samsung/universal_c210/onenand.c
>>>>
>>>> Those files aren't drivers. Those are board specific init functions and
>>>> in my opinion shall stay where they are.
>>>
>>> That's fairy possible, I did only quick inspection and I'll be taking
>>> further look this weekend.
>>
>> May be you should do a further look before sending a heads up about
>> everything you see...
>
> Where are you aiming with this exactly? I clearly stated I didn't do deep
> inspection of these and that there might be mishits
Probably, if you send the heads up email after taking a further look,
the list would be shorter and hit the right people? Don't you think?
Because, if you are going to look into this deeper,
then what the point in sending the "quick look" list?
--
Regards,
Igor.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] List of offending drivers
2012-07-27 14:45 ` Igor Grinberg
@ 2012-07-27 14:49 ` Marek Vasut
0 siblings, 0 replies; 18+ messages in thread
From: Marek Vasut @ 2012-07-27 14:49 UTC (permalink / raw)
To: u-boot
Dear Igor Grinberg,
> On 07/27/12 17:30, Marek Vasut wrote:
> > Dear Igor Grinberg,
> >
> >> Hi Marek,
> >>
> >> On 07/27/12 11:43, Marek Vasut wrote:
> >>> Dear Lukasz Majewski,
> >>>
> >>>> Dear Marek Vasut,
> >>>>
> >>>>> board/samsung/goni/onenand.c
> >>>>> board/samsung/smdkc100/onenand.c
> >>>>> board/samsung/universal_c210/onenand.c
> >>>>
> >>>> Those files aren't drivers. Those are board specific init functions
> >>>> and in my opinion shall stay where they are.
> >>>
> >>> That's fairy possible, I did only quick inspection and I'll be taking
> >>> further look this weekend.
> >>
> >> May be you should do a further look before sending a heads up about
> >> everything you see...
> >
> > Where are you aiming with this exactly? I clearly stated I didn't do deep
> > inspection of these and that there might be mishits
>
> Probably, if you send the heads up email after taking a further look,
> the list would be shorter and hit the right people? Don't you think?
> Because, if you are going to look into this deeper,
> then what the point in sending the "quick look" list?
http://en.wikipedia.org/wiki/Release_early,_release_often ;-)
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot-DM] List of offending drivers
2012-07-26 23:18 [U-Boot] List of offending drivers Marek Vasut
` (2 preceding siblings ...)
2012-07-27 6:28 ` [U-Boot] " Lukasz Majewski
@ 2012-08-01 10:11 ` Andreas Bießmann
3 siblings, 0 replies; 18+ messages in thread
From: Andreas Bießmann @ 2012-08-01 10:11 UTC (permalink / raw)
To: u-boot
Dear Marek Vasut,
On 27.07.12 01:18, Marek Vasut wrote:
> Hello,
>
> Check the following list, it's the list of drivers scattered (misplaced) across
> the tree. The list is not complete and might be inaccurate. But it should give a
> good impression of what I'm going to break soon:
>
> board/atmel/at91rm9200ek/led.c
> board/atmel/at91sam9260ek/led.c
> board/atmel/at91sam9261ek/led.c
> board/atmel/at91sam9263ek/led.c
> board/atmel/at91sam9m10g45ek/led.c
> board/atmel/at91sam9rlek/led.c
these atmel specific led stuff is basically for very early debug
(switching a LED after relocation, another one after board init, ..). It
also provides possibility to use it in assembler code sections e.g.
lowlevel_init.
I do not really care about that cause I normally use JTAG to debug early
code. The led switching at a specific stage could be done by one of the
other generic led drivers.
Beside that, I think for debugging early stage code without JTAG the
serial line is much better than a LED which can only provide two states.
Has anyone thought about that? Has anyone tried to add some
'early_printf' feature?
Best regards
Andreas Bie?mann
^ permalink raw reply [flat|nested] 18+ messages in thread